[Chapter 6] 프로그래밍 에피소드

이 챕터에서는 TDD방식으로 진행하며 많은 리팩토링을 하는 하나의 프로그래밍 에피소드를 설명한다. 두 사람이 짝 프로그래밍을 진행하며 대화 형식으로 진행된다. 만들려고 하는 프로그램은 볼링 게임의 스코어를 계산하는 프로그램이다.

이 글은 책의 내용을 읽고 정리하는 글이기에 내가 이 에피소드를 읽으며 중요하다고 생각되었던 부분, 핵심이라고 생각되는 부분만 따로 정리한 것이다.

🔑 Point

1. 그냥 데이터 저장소가 아니라 실제로 행위를 하는 객체에 집중하자!
2. 테스트를 먼저 작성함으로써 자신이 정말 구현하고 싶은 것에 집중하자!
3. 객체들이 서로 의존하게 되는 상호 의존성을 주의하자!
4. 테스트를 통과하게 하는 가장 간단한 방법을 찾자!
5. 테스트가 통과되었다면 더 이해하기 쉽게 리팩토링을 진행하자!
6. 메서드가 적합한 객체에 위치해 있는지, 객체가 SRP를 잘 지키고 있는지 확인하자!
7. Caller(호출하는 쪽)을 고려하자!
8. 테스트 케이스가 목적에 부합하는 기능을 하는지 확인하자!
9. 네이밍이 정말로 내가 표현하고자하는 의미를 잘 나타내는지 확인하자!
10. 일관성 없는 코드를 주의하자!
11. 코드가 특정한 순서에 의존하는 것을 피하자!
12. 하향식, 그리고 테스트우선 설계를 하자! (가장 높은 수준에서 아래로, 의존성이 (GAME -> FRAME -> THROW)로 흐를 경우 GAME부터 시작)
13. 마지막에는 작성한 전체 프로그램을 쭉 읽으면서 가능한 간단하고 이해하기 쉬운지 확인하자!

결론

원래 이 에피소드의 처음에 간단한 다이어그램을 만들었었다. 하지만 결과적으로 그 다이어그램처럼 구현되지 않았다. 하지만 기존 다이어그램처럼 필요한 것보다 훨씬 복잡하지도 않고, 이해하기도 쉽고 유지보수하기도 쉽다. 확인할 코드 없이 다이어그램을 무작정 만들고 그것을 맹목적으로 따르려고 할 때, 그 다이어그램을 불필요할 수 있다. 그 다이어그램은 가장 최적의 설계가 아닐 수 있다. 테스트를 작성하여 작은 단계를 밟아나가며 최적 설계란 것이 개선될 수 있다는 사실을 알 수 있다.

추가적으로 객체 지향이 항상 답은 아니다. 모든 애플리케이션과 프로그램에 객체 지향 설계를 적용해야할까? 객체 지향을 굳이 적용하지 않고도 객체 지향 설계보다 훨씬 간단한 분할 방식으로 구현될 수도 있다. 항상 객체 지향이 정답은 아니라는 것을 명심해야겠다.