코드를 필요 이상으로 융통성 있게 또는 정교하게 만들 때. (과유불급)
미래에 추가 될 요청사항을 고려해서 코드를 작성할 필요는 있지만, 모든 코딩의 최우선 순위는 어떠한 기능을 만드는 것이지 미래를 준비 하는 것은 아님.
패턴은 프로그래밍 할 때 객체지향 설계에 적합하고, 구조화 시키는데에 효과적인 것은 사실이나, 간단하게 작성할 수 있는 코드를 괜히 복잡하게 만들 수도 있다.
패턴 역시도 설계처럼 지나치면 좋지 않고, 적절한 곳에 사용을 하여야 한다.
사실 위의 두 상황은 지금 이 상황보다는 훨씬 낫다.
설계가 미진하다는 것은 그만큼 개발 시간이 쫓긴다는 소리고, 전 회사에서 너무 자주 겪었던 일이라 눈물이 콸콸...
항상 프로젝트가 1.0에서 머무르게 되고, 1.1을 위한 개발이 아닌 바로 2.0, 3.0을 위한 개발이 되고, 그러다보면 코드 내부에서는 기술 / 설계 부채가 누적 되다보면 되돌이킬 수 없는... 오히려 새로 만드는 게 나을 지경이 되어버리는 작금의 사태들이 너무나도 통탄스러울 뿐이다. 그만큼 리팩터링은 중요하다고 생각하지만 현실적으로 할 수 있는 건지를 모르겠다.
사실 위의 3가지 특히 마지막 부족한 설계부분을 보완 할 수 있는 것이 TDD와 리팩터링이라고 할 수 있다.
TDD와 지속적인 리팩터링은 아래와 같은 대화 형태로 변환하여, 기존 코드를 효율적으로 개선 시킬 수 있어야 한다.
그리고 이 책에선 그 과정을 빨강 / 초록 / 리팩터링 이라는 슬로건을 소개했는데,