📢 창발적 설계로 깔끔한 코드를 구현하자
Getting Clean via Emergent Design
단순한 설계 규칙
1. 모든 테스트를 실행한다.
2. 중복을 없앤다.
3. 프로그래머 의도를 표현한다.
4. 클래스와 메서드 수를 최소로 줄인다.
단순한 설계 규칙을 따른다면
- 우수한 설계가 나올 것이다.
- 코드 구조와 설계 파악이 쉬워질 것이다.
- 단일 책임 원칙(SRP)나 의존 관계 역전 원칙(DIP)과 같은 원칙 적용이 쉬워질 것이다.
📢 단순한 설계 규칙 1: 모든 테스트를 실행하라
Simple Design Rule 1: Runs All the Tests
테스트가 가능한 시스템을 만들려고 애써라.
크기가 작고 목적 하나만 수행하는 SRP를 준수하는 클래스를 만들어라.
테스트 케이스를 많이 작성해라.
DIP와 같은 원칙을 적용하고 의존성 주입, 인터페이스, 추상화 등과 같은 도구를 사용해 결합도를 낮춰라.
테스트 케이스를 만들고 계속 돌려라
이 단순한 규칙은 시스템의 낮은 결합도와 높은 응집력으로 향하는 길이다.
📢 단순한 설계 규칙 2: 리팩터링
Simple Design Rule 2: Refactoring
- 응집도를 높이자.
- 결합도를 낮추자.
- 관심사를 분리하자.
- 시스템 관심사를 모듈로 나누자.
- 함수와 클래스 크기를 줄이자.
- 더 나은 이름을 선택하자.
중복을 없애라
No Duplication
중복은 추가 작업, 추가 위험, 불필요한 복잡도를 뜻한다.
템플릿 메소드 패턴은 고차원 중복을 제거할 목적으로 자주 사용한다.
표현하라
Expressive
개발자가 코드를 명백하게 짤수록 다른 사람이 그 코드를 이해하기 쉽고 결함이 줄어들고 유지보수 비용이 적게 든다.
- 좋은 이름을 선택한다.
- 함수와 클래스 크기를 가능한 줄인다.
- 표준 명칭을 사용한다.
- 디자인 패턴은 의사소통과 표현력 강화가 주요 목적이다.
- COMMAND나 VISITOR와 같은 표준 패턴을 사용해 구현된다면 클래스 이름에 패턴 이름을 넣어준다.
- 단위 테스트 케이스를 꼼꼼히 작성한다.
- 테스트 케이스는 예제로 보여주는 문서이다.
함수와 클래스에 조금 더 시간을 투자하자.
더 나은 이름을 선택하고, 큰 함수를 작은 함수 여럿으로 나누고, 자신의 작품에 조금만 더 주의를 기울이자.
클래스 메서드 수를 최소로 줄여라
Minimal Classes and Methods
극단적으로 중복을 제거하고, 의도를 표현하고, SRP를 준수한다면 오히려 득보다 실이 많아진다.
목표는 함수와 클래스 크기를 작게 유지하면서 동시에 시스템 크기도 작게 유지하는 데 있다.
📢 결론
경험을 대신할 단순한 개발 기법은 없지만,
이 장에서 소개하는 단순한 설계 규칙을 따른다면 (오랜 경험 후에야 익힐) 우수한 기법과 원칙을 단번에 활용할 수 있다.
📖 느낀점
책을 읽으며 나중에 코드를 다시 읽을 사람이 결국 나일 것이다라는 문장이 있었다.
가끔 과거의 내가 짠 코드를 한참을 들여봐야 이해할 수 있을 때가 있다.
그런 면에서 오늘 읽은 챕터가 참 많이 와닿았다.
조금 더 주의를 기울여야겠다, 미래의 나를 위해서라도.
