반응형
깔끔한 코드를 구현하기 위한 4가지 규칙!
- 모든 테스트를 실행하라
- 설계는 의도한 대로 돌아가야 한다. 모든 테스트 케이스를 항상 통과해야한다.
- 이 때 테스트가 불가능한 시스템이 있는데 이는.. 항상 논란의 여지가 있다. 과연 검증이 불가능한 시스템을 둬야하는가
- 왜 테스트 코드를 짜야하냐면 결합도가 높아지면 테스트 코드를 작성하기 힘들어지기 때문에 테스트 코드를 짜다보면 결합도도 낮아진다.
- 리팩토링
- 테스트 코드를 모두 작성하였다면 이제 코드와 클래스를 정리하라
- 이 때 코드를 정리하면서 다른 기능을 해치는거 아닐까 걱정하지 않아도 된다. 1번 테스트 코드를 전부 작성하였다면!
- 시스템 관심사를 모듈로 나누고 이름을 좀 더 기능에 적합하게 수정하고, 중복 코드 제거, 클래스 메소드 갯수를 최한으로 줄이는 단계이다.
- 표현하라
- 요즘 내가 느끼는 내용이다.
- 대부분 회사의 시스템은 유지보수 중인 시스템이고 그 중간중간 신규 서비스를 내놓는다. (우린 아니지만) 이 때 자연스럽게 새로 온 개발자는 기존의 코드를 이해하느라 보내는 시간이 엄청 길어진다.
- 단순히 코드를 뜯어보는게 아니라 의도를 모르면 해당 function을 오해할 여지도 있다. 반대로 의도가 명확한 function은 코드분석도 쉬워졌다.
- 이를 위해선 자연스럽게 함수나 클래스의 크기를 줄여야한다. 너무 커지면 이 함수가 대체 뭘 하는 함수인지 알기가 너무나도 어렵다.
- 역시 여기에도 테스트 코드가 들어간다. 코드를 뜯어보려는 클래스나 메소드의 테스트 코드를 보면 의도를 알 수 있다. (이 클래스, 메소드가 사용될 예제를 보여주는 코드이기 때문에)
- 마지막은 노오오오려어어어억, 일단 개발하기만 하면 땡이 아니라 다른 개발자가 읽기 쉽게 만들기 위한 노력을 많이 하지 않는데 여기에도 시간을 쏟아야한다. 보통 높은 확률로 이 코드를 볼 다음 개발자도 나다.
- 클래스와 메서드 수를 최소로 줄여라
- 위에 중간중간 나온 얘기이지만 동시에 주의할 점은 너무 코드를 작게 줄이다가 숫자가 많아진다는 것이다.
- 숫자도 동시에 최대한 줄여야 한다.
반응형