Topic 8 좋은 설계의 핵심
데이비드 토머스, 앤드류 헌트
느낌표 ! (인상 깊은 문장 | 문맥)
잘 설계된 코드는 바뀜으로써 사용하는 사람에게 맞춰져야 한다. 그래서 우리는 ETC 원칙을 따른다. 바꾸기 더 쉽게. ETC(Easier to Change). 이게 전부다.
p.39
생각을 해보면 클린 코드, 테스트 주도 개발, 리펙토링, 디자인 패턴 등 여러 기법들을 보면 궁극적으로는 더 바꾸기 쉽게를 지향하는 것 같다. 그래서 코드를 작성할 때 작성한 코드가 변경하기 쉬운 코드인가 의식적으로 비판해보는 노력도 필요하다고 생각이 들었다.
스스로 자꾸 물어보라. ‘내가 방금 한 일이 전체 시스템을 바꾸기 쉽게 만들었을까, 어렵게 만들었을까?’ 파일을 저장할 때마다 물어보라. 테스트를 쓸 때도, 버그를 수정할 때도 물어보라.
p.40
바꾸기 쉬운지 물어보고 점검하는 것이 마스터 키라는 느낌이 든다. 바꾸기 쉽다는 뜻은 책임이 명확히 분리되어야 가능한 것이며 책임이 명확하게 분리가 되기 위해서는 도메인의 역할이 명확해야 가능하기 때문이다. TDD 의 단점 중 하나가 나중에 기능이 변경되었을 때 기존의 테스트 케이스를 수정하는 노력과 수정하면서 테스트의 구멍이 생기기도 한다는 것이다. 그렇지만 변경이 쉽게 코드를 작성했다면 유닛 테스트부터 명확히 테스트를 작성할 수 있을 것이다. 각 도메인, 기능에 책임이 명확하기 때문이다. 즉 변경에 유리하게 코드를 작성했다면 테스트 케이스 또한 추후 변경에 용이할 것이다. 필자의 경우 리펙토링을 할 때 코드를 더 줄일 수 있나, 중복된 코드를 함수로 묶을 수 있는지 우선적으로 확인하는데 변경이 쉬운지는 생각하지 못했다. 그렇지만 해당 인용구를 보며 리펙토링을 잘못하고 있었다는 생각이 든다.
첫 번째로, 앞으로 어떤 모습으로 바뀔지 잘 모르겠을 때 언제건 궁극의 ‘바꾸기 쉽게’ 라는 길을 선택한다. 바로 여러분이 작성하는 코드를 교체하기 쉽게 만들도록 노력하는 것이다.
…
두 번째는 이런 경우를 여러분의 직관을 발전시키는 기회로 삼으라는 것이다.
p.40
모든 것을 완벽하게 할 수 없기 때문에 바꾸기 쉽게 코드를 작성해야한다. 또 모든 것을 완벽하게 할 수 없기 때문에 완벽에 가까워지려 노력해야한다. 그러기 위해서 저자가 추천하는 방식은 일지에 현재 상황과 선택, 변경 사항을 정리해두고 나중에 이 코드를 바꿔야할 때 뒤를 돌아보고 자신을 피드백을 하라고 권하고있다.
Topic 8 느낌
Topic 8 에서는 코드를 바라보는 마스터 키를 쥐어준다.