클린코드 14장 - 점진적인 개선

  이 장은 점진적인 개선을 보여주는 사례 연구다. 우선, 출발은 좋았으나 확장성이 부족했던 모듈을 소개한다. 그런 다음, 모듈을 개선하고 정리하는 단계를 살펴본다. 

 

이 책 14장에서의 예제는, 여기에서 설명하기에 어려운 부분이 있어서, 책을 직접 참고하고 따라가며 학습하는 것이 좋을 것 같다. 이 곳에서는 간략하게만 정리하도록 하겠다.

 

목록 14-2 ~ 14-7 까지는 완성된 코드를 보여준다.

 

어떻게 짰느냐고?

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

처음 듣는 이야기가 아니라고 생각한다. 초등학교 시절 선생님들도 작문할 때 초안부터 쓰라고 하셨다. 깔끔한 작품을 내놓으려면 단계적으로 개선해야 한다고 가르치려 애쓰셨다. ( 내 대학원시절 논문들도 그렇게 다듬어졌다 )

  대다수 신찬 프로그래머는 일단 프로그램이 '돌아가면' 다음 업무로 넘어간다. 경험이 풍부한 전문 프로그래머라면 이런 행동이 전문가로서 자살 행위라는 사실을 잘 안다.

 

  14-8은 지저분한 초기 코드를 보여주고 있다. 처음부터 지저분한 코드를 짜려는 생각은 아무도 없을 것이다. 하지만 어느 순간 프로그램은 내 손을 벗어난다.

 

  14-9는 Boolean만 지원하던 초기 버전이다. 뒤에 나올 코드는 String과 Integer라는 인수 유형 두 개만 추가했을뿐이다. 그뿐인데 코드가 엄청나게 지저분해졌다. 

 

그래서 멈췄다

  추가할 인수 유형이 적어도 두 개는 더 있었는데 그러면 코드가 훨씬 더 나빠지리라는 사실이 자명했다. 코드 구조를 유지보수하기 좋은 상태로 만들려면 지금이 적기라 판단했다. 그래서 리팩터링을 시작했다.

  

점진적으로 개선하다

  프로그램을 망치는 가장 좋은 방법 중 하나는 개선이라는 이름 아래 구조를 크게 뒤집는 행위다. '개선' 전과 똑같이 프로그램을 돌리기가 아주 어렵기 때문이다.

  그래서 저자는 TDD 라는 기법을 사용했다. 언제 어느 때라도 시스템이 돌아가야 한다는 원칙을 따른다. 시스템이 테스트를 모두 통과하면 올바로 동작한다고 봐도 좋다.

 

위와 같은 흐름으로 차근차근 개선하는 과정이 책에 나타나 있다.

 

소프트웨어 설계는 분할만 잘해도 품질이 크게 높아진다. 적절한 장소를 만들어 코드만 분리해도 설계가 좋아진다. 관심사를 분리하면 코드를 이해하고 보수하기 훨씬 더 쉬워진다. 

 

결론

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

 

  나쁜 코드를 깨끗한 코드로 개선하는 것보다, 처음부터 코드를 깨끗하게 유지하는 것이 상대적으로 쉽다. 그러므로 코드는 최대한 깔끔하고 단순하게 정리하자. 절대로 썩어가게 방치하면 안 된다.