<aside> 💡
</aside>
우리팀의 좋은 코드는 아래와 같은 코드로 정의한다.
a. 읽기 쉬운 코드 - 코드를 읽기 쉽도록 해야 협업에서 기술적 동기화 작업과, 리펙토링, 코드리뷰에서 더욱 원활하게 진행할 수 있다.
b. 중복이 없는 코드 - 똑같은 코드의 반복은 쓰레기다. 기능에 대해 함수로 분리하여 구현하고, 조합함으로써 깔끔한 코드를 지향하자.
c. 테스트가 쉬운 코드 - 테스트 코드의 이점은 크게 두 가지가 있다. 실제 동작함을 증명하며, 기능의 이해를 돕는다. 테스트 코드를 적음으로써 최고의 효율을 취하기 위해서는 점진적인 개선이 가능하도록 테스트 코드가 지지해주는 것이다.
버그에 대한 응급처치를 취할 수 있다. 깨끗한 코드를 뒤로하고 기능 구현에 집중했을 수도 있다. 당장에 깔끔하게 구현하지 못해 임의로 동작하도록 구현할 수도 있다. 이러한 행위들에 대해서 ＇부채＇라고 우리는 명명하며 이를 꼭 상환하는 의무를 지도록 한다. 잠시 기술 부채를 두고 문제를 해결하는 것도 중요하다. 그러나 부채가 많아질수록 유지보수에 더 큰 비용이 드는 위험을 방지하기 위해 제 때에 갚도록 하자.
우리는 명명화와 코드 스타일의 일관성을 지켜야 한다. 만약 컨벤션에 들어맞지 않는 코드를 발견한다면, 리뷰 시 최대한 잡아주도록 모든 팀원이 노력해준다.
파레토 법칙에 의하면 80%의 버그는 20% 코드에서 나온다. 20% 코드 지점을 찾아 이 부분만 테스트 코드를 작성하든, 새롭게 작성되는 영역에만 테스트 코드를 작성하던 선택이다. 그러나 결국 투입되는 비용 대비 결과물이 있어야 하는 엔지니어링의 영역이기 때문에 완벽한 테스트코드는 없다.
우리는 기능에 집중하여 테스트 코드를 작성하도록 한다. public으로 열린 기능이 있다면 최대한 테스트 코드로 먼저 작성하고, 이를 구현하도록 노력한다.