12장. 창발성
창발적 설계로 깔끔한 코드를 구현하자
단순한 설계 규칙 네 가지가 소프트웨어 설계 품질을 크게 높여준다고 믿는다.
- 모든 테스트를 실행한다.
- 중복을 없앤다.
- 프로그래머 의도를 표현한다.
- 클래스와 메서드 수를 최소로 줄인다.
단순한 설계 규칙 1: 모든 테스트를 실행하라
무엇보다 먼저, 설계는 의도한대로 돌아가는 시스템을 내놓아야 한다. 즉, 문서를 완벽하게 설계해도 실제 시스템이 설계한대로 돌아가질 않는다면 그 가치는 인정받기 어렵다.
따라서 테스트를 철저히 거쳐 모든 테스트 케이스를 항상 통과하는 시스템이 되어야 한다. (테스트가 가능한 시스템)
테스트가 가능한 시스템을 만들려고 애쓰면 설계 품질이 더불어 높아진다.
결합도가 높으면 테스트 작성이 어려워지는데, 테스트 케이스를 가능한 많이 작성하면 작성할수록 개발자는 DIP와 같은 원칙을 적용하고, 의존성 주입, 인터페이스, 추상화 등과 같은 도구를 사용해 결합도를 낮추려 애쓸 것이다. 이는 결국 설계 품질이 더욱 높아지는 과정이다.
단순한 설계 규칙 2~4: 리팩터링
테스트 케이스를 모두 작성했다면 이제 코드와 클래스를 정리해도 괜찮다. 구체적으로는 코드를 점진적으로 리팩터링 해나간다. (개인적으로 마틴 파울러의 리팩토링 책을 추천한다!)
리팩토링을 하기 위해 필수 준비과정이 바로 테스트 케이스를 가능한한 많이 작성하는 것이다. 그래야 리팩토링시 테스트가 꺠지는지 확인할 수 있다. 리팩토링을 통해 좀 더 견고한 시스템을 만들 수 있도록 응집도를 높이고, 결합도를 낮추고, 관심사를 분리하고, 시스템 관심사를 모듈로 나누고, 함수와 클래스 크기를 줄이고, 더 나은 이름을 선택하는 등 다양한 기법을 동원한다.
중복을 없애라
리팩토링 책에도 나오지만 제일 최악의 설계가 중복된 코드들이 덕지덕지 사용되어 있는 시스템이다. 이는 리팩토링의 필요성을 못느끼고 변경할 떄마다 매번 같은 코드를 작성하게 되는 것이다. 중복 코드를 최대한 줄이고 모듈로 빼거나 컴포넌트로 만들면 재활용 할 수 있는 장점이 생긴다.
표현하라
자신이 이해하는 코드를 짜기는 쉽다.
소프트우어 프로젝트 비용 중 대다수는 장기적인 유지보수에 들어간다. 이 말은 즉슨 내가 알아보기 쉬운 코드를 짜는 것이 아닌 남들이 협업하는 동료들이 혹은 미래의 후임들이 보기에 쉬운 코드를 짤 수 있어야 유지보수에도 굉장히 좋다.
- 좋은 이름을 선택한다.
- 함수와 클래스 크기를 가능한 줄인다.
- 표준 명칭을 사용한다.
- 단위 테스트 케이스를 꼼꼼히 작성한다.
클래스와 메서드 수를 최소로 줄여라
중복을 제거하고 의도를 표현하고 SRP를 준수한다는 기본적인 개념도 극단적으로 치달으면 득보다 실이 많아진다. (배보다 배꼽이 더 큰 경우다.) 클래스와 메서드 크기를 줄이자고 조그만 클래스와 메서드를 수없이 만드는 사례도 없지 않다. 그래서 함수와 클래스 수를 가능한 줄이라고 제안한다.
결론
위의 조언들은 그냥 나온 것이 아닌 수십년동안 쌓은 경험의 징수다. 결국 프로젝트를 성공적으로 이끌기 위해서는 수많은 이론을 공부하는 것이 아닌 수많은 경험과 노하우가 쌓여서 만들어 가는 것이다.
References
'공부 기록' 카테고리의 다른 글
[클린코드] 11장. 시스템 (0) | 2024.05.01 |
---|---|
[클리코드] 10장. 클래스 (0) | 2024.04.26 |
[클린코드] 9장. 단위 테스트 (0) | 2024.04.23 |
[클린코드] 8장. 경계 (0) | 2024.04.22 |
[클린코드] 7장. 오류 처리 (1) | 2024.04.19 |
댓글