개요

코드를 짜면서, 여러가지 난관에 봉착할 수도 있다.

과도한 설계

코드를 필요 이상으로 융퉁성 있게 또는 정교하게 만들 때 이를 과도한 설계라고 한다.
마치 미래의 요구사항을 알고있는 듯이 설계를 하는 것을 의미한다.
예상이 맞았다면, 문제 없이 좋게 흘러가겠지만 갑자기 요구사항이 바뀐다면? 정작 기능은 구현하지 못하고 코드를 설계하는데만 시간을 허비할 수도 있다.
이를 완화하기 위해 시스템을 영역별로 나누어서 협업할 때도 있는데, 이 때 필요한 기능을 서로 구현해서 중복되는 코드가 양산될 수 있는 가능성이 있다.

패턴 만능주의

패턴은 물론 객체지향 설계의 우아한 방법이다.
하지만 닭 잡는데 소 잡는 칼을 사용할 필요는 없을 때가 있다.
잘 구분해서 사용해야 한다.
작고 단순하고 이해하기 쉬운 코드를 만드는 것에 주의를 기울여야 한다.

미진한 설계

과도한 설계보단 미진한 설계가 훨씬 많다.
시간도 없고 리팩토링 할 시간도 주어지지 않을 때, 어떤 것이 훌륭한 설계인지 모를 때 등등..
설계를 잘못 하는것은 빚 이다.
적을수록, 빨리 수정할 수록 싼 값에 갚을 수 있지만 많을수록, 미뤄둘 수록 큰 비용을 지불해야 한다.

테스트 주도 개발(TDD)과 지속적인 리팩터링

테스트 주도 개발은 다음과 같다.

1. 질문: 테스트를 작성함으로써 시스템에 질문한다.
2. 대답: 테스트를 통과하는 코드를 작성해 질문에 대답한다.
3. 정제: 아이디어를 통합하고 불필요한 것은 제거하고 모호한 것은 명확히 해서 대답을 정제한다.
4. 반복: 다음 질문을 물어 대화를 계속한다.

TDD와 지속적인 리팩터링에 대해 Kent Beck이 내건 슬로건은 빨강, 초록, 리팩터링 이다.

1. 빨강: 코드가 해야 할 일을 예상하고 이것을 나타내는 테스트를 작성한다.
2. 초록: 테스트를 통과하도록 임시 방편으로라도 프로그램을 작성한다. 이 단계에서는 코드 중복, 단순함, 명확한 설계 같은 것을 고민할 필요가 없다.
3. 리팩터링: 테스트를 통과한 코드의 설계를 개선한다.

이런 방법은 생산성을 극대화하는 좋은 방법이다. TDD에 대한 책으로 Test-Driven Development 을 추천받았다.

리팩토링과 패턴

디자인패턴과 리팩토링은 관계가 있다.
패턴은 도달하고 싶은 곳이고, 리팩터링은 그 곳으로 가는 방법이다