창발적 설계로 깔끔한 코드를 구현하자
: 착실히 따르기만 해도 우수한 설계를 보장할 수 있는 규칙이 있다. TDD로 유명한 켄트 백이 제안한 4가지 규칙인데 다음과 같다.
•
모든 테스트를 실행한다.
•
중복을 없앤다.
•
프로그래머의 의도를 표현한다.
•
클래스와 메서드 수를 최소로 줄인다.
: 이 네 가지 규칙은 우수한 설계의 창발성을 촉진해줄 수 있다. 더구나 SRP나 DIP와 같은 원칙들을 적용하기 쉽게 도와준다.
단순한 설계 규칙 1: 모든 테스트를 실행하라.
: 소프트웨어의 가장 중요한 가치 중 하나는 구현이다. 문서로 아무리 완벽한 설계, 명세를 작성해두어도 실제로 구현된 시스템이 의도대로 동작하지 않는다면 그것은 무용지물이다.
: 우리는 우리가 구현한 시스템이 우리의 의도대로 동작함을 증명해보일 수 있는 가장 간단한 방법을 알고 있다. 바로 테스트 코드다.
: 모든 테스트를 실행하려면 일단 모든 테스트가 가능하게 만들어야 한다. 생각보다 의외로 테스트가 불가능한 코드는 우리 곁에 흔하게 존재하고 있다.
⇒ 여기서 얘기하는 테스트는 단위 테스트다.
: 코드를 대충 짜고 테스트 코드를 작성하려할 때, 수많은 의존성에 대해 모킹을 처리해준다거나 테스트 코드 결과가 실행할 때마다 다른 결과가 나온다면 그것은 좋지 않은 테스트 코드다.
: 즉 결합도가 높게 설계된 시스템일수록 테스트 코드를 작성하기 어렵고 이는 곧 당신의 시스템이 객체지향적으로 좋은 설계가 아님을 의미한다.
: DIP나 의존성 주입, 인터페이스, 추상화 등과 같은 도구를 사용해 결합도를 낮춰 테스트가 쉽게한다면 당신의 설계 품질은 향상될 것이다.
단순한 설계 규칙 2~4: 리팩터링
: 테스트 케이스를 모두 작성했다면 이제 코드와 클래스를 정리하자. 코드를 점진적으로 리팩터링해나가며 설계를 점검하자.
: 리팩터링으로 변경된 코드가 정상적으로 동작하지 않을 것이라 공포에 떨지 않아도 괜찮다. 우리에겐 테스크 코드가 있으니까!
: 리팩터링 단계에서는 설계 품질을 높이는 기법이라면 무엇이든 적용해도 괜찮다고 한다. 응집도를 높이고 결합도를 낮추고, 관심사를 분리하고 시스템 관심사를 모듈로 나누고, 함수의 클래스의 크기를 줄이고 더 나은 이름을 선택하는 등 다양한 기법을 총 동원하자.
중복을 없애라
: 깔끔한 시스템을 만들고 싶다면 중복을 제거하라.
: 소규모 재사용(하나의 책임을 수행하는 클래스로 분리)를 제대로 해야 대규모 재사용도 할 수 있다.
: Template Method 패턴은 고차원 중복을 제거할 목적으로 자주 사용하는 기법이다.
표현하라
: 소프트웨어의 대부분은 유지보수다. 유지보수 시 버그의 발생가능성을 낮추려면 코드의 가독성을 향상시켜야 한다.
•
좋은 이름을 선택하라.
•
함수와 클래스의 크기를 가능한 줄인다.
•
표준 명칭을 사용하라.
•
단위 테스트 케이스를 꼼꼼히 작성한다.
: 위와 같은 노력들 외에도 가장 좋은 방법은 말 그대로 노력이다.
: 처음보는 사람이 코드를 읽어도 이해하기 쉽게 하려는 고민에 대한 노력은 꼭 필요하다. 보통 당신이 짠 코드를 나중에 코드를 읽을 사람은 당신일테니까
: 오랜만에 보게된 코드는 그 맥락을 파악하는 것이 힘들다. 우리는 그 맥락을 코드로 제공해줄 수 있게끔 노력해야 한다.
: 주의를 기울여라
클래스와 메서드 수를 최소로 줄여라
: 뭐든 과하면 독이 된다. 그래서 이 말은 ‘가능한’이 전제된다는 걸 기억하자.
: 클래스마다 무조건 인터페이스를 생성할 필요는 없다. 굳이 자료 클래스와 동작 클래스를 무조건 분해할 필요도 없다.
: 목표는 함수와 클래스 크기를 적당하게 작게 유지하면서 동시에 시스템 크기도 작게 유지하는 것에 있다.
: 이 규칙은 앞서 말한 네 가지 규칙 중 그 중요도가 가장 낮다. 그 말은 우선순위를 고려해서 리팩토링시에 참고하라는 뜻이다.
결론
: 가장 빠른 성장을 위해선 경험이 중요하다. 하지만 이 장에서 설명한 4가지 규칙을 착실히 따른다면 우린 그 경험이 조금 모자라더라도 좋은 설계에 빠르게 가까워질 수 있다.
