Intro

깔끔한 작품을 내놓으려면 단계적으로 개선해야 한다.

어떻게 짰느냐고

깨끗하고 우아한 프로그램을 한 방에 뚝딱 내놓을 수 없다. 프로그래밍은 과학보다 공예에 가깝다.

깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다.

그래서 멈췄다

• 처음부터 지저분한 코드는 아니었고 제한적으로 기능을 지원할 때는 괜찮았지만 기능 유형을 추가할 때마다 지저분해짐
• 추가할 기능 유형이 남았지만 코드가 너무 지저분해지므로 멈추고 리팩터링

점진적으로 개선하다

개선이라는 이름으로 구조를 크게 뒤집는 것은 프로그램을 망치는 방법이다.

테스트 주도 개발(Test-Driven Development, TDD)

• TDD는 언제 어느 때라도 시스템이 돌아가야 한다는 원칙을 따른다.
• 즉, TDD는 시스템을 망가뜨리는 변경을 허용하지 않는다.
• 변경 전후 시스템이 똑같이 돌아간다는 사실을 확인하려면 언제든 실행이 가능한 자동화된 테스트 슈트가 필요

마치며

그저 돌아가는 코드만으로는 부족하다. 돌아가는 코드가 심하게 망가지는 사례는 흔하다.
단순히 돌아가는 코드에 만족하는 프로그래머는 전문가 정신이 부족하다.

나쁜 코드보다 더 오랫동안 더 심각하게 개발 프로젝트에 악영향을 미치는 요인도 없다. 나쁜 일정은 다시 짜면 된다. 나쁜 요구사항은 다시 정의하면 된다. 나쁜 팀 역학은 복구하면 된다. 하지만 나쁜 코드는 썩어 문드러진다.

반면 처음부터 코드를 깨끗하게 유지하기란 상대적으로 쉽다. 아침에 엉망으로 만든 코드를 오후에 정리하기는 어렵지 않다. 더욱이 5분 전에 엉망으로 만든 코드는 지금 당장 정리하기 아주 쉽다

그러므로 코드는 언제나 최대한 깔끔하고 단순하게 정리해야 한다.