함수나 클래스는 다른 프로그래머가 당연하게 여길 만한 독작과 기능을 제공해야 한다.
너무나 당연한 이야기이지만 '당연하게'의 기준이 남들과 다를 수 있기 때문에 역시 코드리뷰는 필수다.
모든 경계 조건을 테스트하는 테스트 코드를 작성해야 한다.
테스트 코드를 작성할 때 에러가 발생할 수 있는 케이스들에 대해 깊이 생각하는 습관을 들이자.
고차원과 저차원 개념을 올바르게 분리해야 한다.
고차원의 개념은 저차원의 구현 정보에 무지해야 한다.
개념의 분리를 위해 추상화를 하는 것은 올바르다고 생각하지만 현실적으로 무한히 추상화 단계를 만들 수는 없지 않을까? 내 식견이 짧아서 그렇게 생각되는 걸까?
함수의 동작을 제어하는 인수를 추가하지 않아야 한다.
boolean, enum, int 등의 인수로 함수의 동작을 제어하면 안된다. 케이스별로 함수를 분리하자.
If/Else, Switch/Case 문보다 다형성을 사용하라.
이 부분이 가장 어려운 부분... 코드를 읽어보면 알겠는데 막상 코드를 짤 때는 자연스럽게 나오지 않는다. T와 좀더 친해져야 할 것 같다.
매직 숫자는 명명된 상수로 교체하라.
쉬운 내용이지만 급할 때마다 무시되는 경우가 있어서 굳이 기록한다.
조건을 캡슐화하라.
마찬가지로 쉬운 내용이지만 급할 때마다 무시되는 경우가 있다.
테스트는 빨라야한다.
테스트가 느릴 경우 급할 때 반드시 무시하게 되므로 빠르게 돌아가도록 노력해야 한다.
빠르다, 느리다의 기준은 어느 선에서 정할 수 있을까? 백엔드 Unit Test 러닝타임이 점점 길어지고 있는데 어느 선에서는 mocking을 더 해야할 것 같다.
