정답 대신 경험

우연한 중복인지 의심해보기

이전에는 명령의 집합, 컴포넌트 구조, CSS가 중복되면 바로 추출했다.

더 나아가서, 중복이 예상되어도 미래를 위해 추출했다. 당장엔 이뻐보였다.

 

이러다보면 차이점이 생길 때마다 완벽한 추상화를 위해 오버 엔지니어링을 할 위험이 있고,

좋은 코드의 본질을 잊어버릴 때가 있다. 

 

결국 이해하기 쉽고, 확장하기 쉬운 코드가 좋은 코드 아니었던가?

추상화의 과정이 시간을 과하게 뺏어가고, 그 결과가 이해하기 어렵다면 시간을 한번 더 뺏는다.

중복제거만을 위한 추상화는 분명 정답이 아니라고 느꼈다.

 

서비스와 기획은 너무나도 빨리 바뀐다. 구현하는 방법 또한 계속 바뀐다.

미래를 예지한 것이 아니면, 결국 완벽한 추상화는 없다.

일반화의 끝은, 결국 아무것도 하지않은 기본 API들과 태그들이었다.

 

그렇다면 적절한 추상화의 기준을 어떻게 정할까?

레벨 1때 느낀 점 중 하나가 '해봐야 안다.' 였다.

마찬가지 이다. 섣부른 중복제거는 중복을 잘 추출했는지 확신할 수 없다.

앱 안에서, 또는 컴포넌트 안에서 매우 많은 중복코드를 작성 하고 나서야 비로소 중복 제거의 필요성이 보였다.

 

근거있는 중복제거를 하고자 한다.

우선 중복코드를 작성해야 한다. 그런 다음에 필요한 것을 추출해야 한다.

그럼에도 당장 만들어낸 이 추상화조차 영원하지 않다는 것을 알아야 한다.

 

가장 유연한 코드는 가장 의존성이 없는 코드였다.

가장 설득력 있는 근거는 경험

정답은 없다. 그리고 정답이 없으면 고통스럽다. 그렇다고 정해진 정답대로 생각하면 안된다.

되돌아보면, 고통을 피해 고민없이 설계하는 순간 무언가 꼬이기 시작했다.

중복을 제거하는 기준, 컴포넌트를 나누는 기준, 전역상태를 사용하는 기준 등

코딩하며 세워야 하는 정답없는 기준들은 너무 많았다. 무엇을 기준으로 근거를 찾을까?

 

실패 경험은 참 쉬우면서도, 너무 귀찮지만, 가장 확실한 근거를 확보하는 방법이라 느꼈다.

고민을 피하거나 포기하지 않고 실패하면서 점진적으로 추상화를 해야한다고 느꼈다. 

시간을 대가로 집중을 흐리지 말기

시간을 최대로 쏟는 것이 곧 정답이라 믿었다.

하지만 '같은 시간을 투자하고 더 많은 것을 얻기'를 연습해야 한다고 느꼈다.

 

같은 집중력에서, 시간투자는 언제나 더 좋은 결과를 준다.

결과가 안좋았다면 다음엔 추가로 시간을 더 투자하면 되는 것이었다.

 

추가시간은 포기로 즉각 얻을 수 있다. 얼마든지 포기할 것은 있다.

 

다만 포기를 대가로 얻으려는 것에 익숙해지다 보면

효율을 생각 못하고 집중이 풀리는 일이 있었다.

 

뭐든지 포기도 적당히, 효율도 적당히 챙겨가는 연습을 해야겠다고 느꼈다.