[Clean Code] 클린 코드(창발성) - 17

창발성

창발적 설계로 깔끔한 코드를 구현하자

착실하게 따르기만 하면 우수한 설계가 나오는 4가지 규칙이 있다면 따르겠는가?
SRP나 DIP와 같은 원칙을 적용하기 쉬워진다면 따르겠는가?

4가지(중요도 순)

1. 모든 테스트를 실행한다.
2. 중복을 없앤다.
3. 프로그래머 의도를 표현한다.
4. 클래스와 메서드 수를 최소로 줄인다.

---

모든 테스트를 실행하라

무엇보다 설계는 의도한 대로 돌아가는 시스템을 내놓아야 한다.
문서로는 시스템을 완벽히 설계했지만, 의도대로 돌아가는지 검증할 수 없다면 가치를 인정받기는 힘들다.

테스트를 철저히 거쳐 모든 테스트 케이스를 항상 통과하는 시스템은 '테스트가 가능한 시스템' 이다.

SRP를 준수하는 클래스는 테스트가 훨씬 더 쉽다.
TC가 많은수록 개발자는 테스트가 쉽게 코드를 작성한다.

결합도가 높으면 TC를 작성하기 어렵다.

-> 'TC를 만들고 계속 돌려라'라는 규칙을 따르면 시스템은 낮은 결합도, 높은 응집도의 결과를 얻을 수 있다.

---

리팩터링

TC를 모두 작성했다면 코드와 클래스를 정리해도 괜찮다.
코드를 정리하며 TC를 돌려 시스템의 기존 기능을 망가뜨리지 않았는지 확인한다.

중복을 없애라

중복은 추가작업, 추가위험, 불필요한 복잡도를 뜻한다.

똑같은 코드

-> 비슷한 코드는 더 비슷하게 고쳐주면 리팩터링이 쉽다.

ex) 미국과 유럽연합 각각에 근무하는 직원들의 휴가 일수를 계산하는 코드 작성

1. 지금까지 근무한 시간을 바탕으로 휴가 일수 계산
2. 휴가 일수가 직원이 속한 지역의 법정 일수를 만족하는지 확인
3. 휴가 일수를 적용

이때, 미국과 유럽연합 각각의 직원들은 2번이 달라야 한다.
미국 - 미국 최소 법정 일수
유럽연합 - 유럽연합 최소 법정 일수

템플릿 메소드 패턴

이처럼 하위 클래스는 중복되지 않는 정보만 제공한다.

표현하라

대다수는 엉망인 코드를 접하거나 만든 경험이 있을 것이다.
자신이 이해하는 코드를 만들기는 쉽다.
코드를 짜면서 구석구석을 이해하며 짜니깐
BUT, 다른 사람이 해당 코드를 이해하기는 어렵다.

1. 좋은 이름을 선택하라
2. 함수와 클래스 크기를 가능한 줄인다.
3. 표준 명칭을 사용한다.
   커맨드/방문자 패턴을 사용한다면 클래스 이름에 COMMAND/VISITOR를 넣어준다.
4. 단위 테스트 케이스를 꼼꼼히 작성한다.
5. 노력하라
   코드만 돌린 후에 다음 문제로 직행하는 사례가 너무 흔하다.
   나중 사람을 위해 조금이라도 노력하자.

클래스와 메서드 수를 최소로 줄여라

SRP를 준수하기 위해 극단으로 치달으면, 클래스와 메서드 수가 너무 많아진다.
따라서 가능한 작게 유지하면서 시스템 크기도 작게 유지하라.

결론

경험을 대신할 개발 기법은 없다.