14장. 점진적인 개선

이 장에서는 명령행 인수(argument) 구문분석기를 구현하고, 점진적으로 개선하는 것을 보여준다.

코드가 대부분이라 여기에 적을수는 없지만 모두 타이핑 해봤다. (진짜다..)

따라하면서 느낀점은, 테스트를 꼼꼼하게 작성하고 개선을 정말 조금씩 한다는거다.

나는 보통 한번에 막 고치는 스타일인데 급한 성격을 가라앉히고 천천히 개선하는 습관을 들여야겠다.

읽다가 옳다구나! 하는 문구정도만 정리해본다.

지난 경험에서 얻은 교훈

=> 프로그래밍은 과학보다 공예에 가깝다는 사실. 깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다는 의미다.

프로그램을 망치는 가장 좋은 방법 중 하나는 개선이라는 이름 아래 구조를 크게 뒤집는 행위다. 

=> 돌아올 수 없는 강을 건너지 말고 조금씩 개선. TDD를 이용하면 언제나 돌아가는 프로그램을 보장 받을 수 있다. 

=> "이정도를 통과하면 정상이라고 봐도 된다." 정도로 테스트를 만들고, 뜯어 고치기 시작한다.

리팩터링을 하다보면 코드를 넣었다 뺐다 하는 사례가 아주 흔하다.

단계적으로 조금씩 변경하며 매번 테스트를 돌려야 하므로 코드를 여기저기 옮길 일이 많아진다.

리펙터링은 루빅 큐브 맞추기와 비슷하다. 큰 목표를 이루기 위해 자잘한 단계를 수없이 거친다. 

각 단계를 거쳐야 다음 단계가 가능하다.

소프트웨어 설계는 분할만 잘해도 품질이 크게 높아진다.

=> 관심사를 분리하면 코드를 이해하고 보수하기 훨씬 더 쉬워진다.

단순히 돌아가는 코드에 만족하는 프로그래머는 전문가 정신이 부족하다.

나쁜 코드보다 더 오랫동안 더 심각하게 개발 프로젝트에 악영향을 미치는 요인도 없다.

이미 썩은 코드를 개선하는건 비용이 엄청나게 많이 든다.

코드가 썩어가며 모듈은 서로서로 얽히고설켜 뒤엉키고 숨겨진 의존성이 수도 없이 생긴다.

오래된 의존성을 찾아내 깨려면 상당한 시간과 인내심이 필요하다.

반면 처음부터 코드를 깨끗하게 유지하기란 상대적으로 쉽다.

아침에 엉망으로 만든 코드를 오후에 정리하기는 쉽다. 더욱이 5분전에 엉망으로 코드는 지금 당장 정리할 수 있다.

그러므로 코드는 언제나 최대한 깔끔하고 단순하게 정리하자. 절대로 썩어가게 방치하면 안된다.