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

이 글은 로버트 마틴의 '클린 코드'를 읽고 TIL(Today I Learned)로써 정리한 내용을 기록하는 글입니다.
자세한 내용은 책을 통해 확인하실 수 있습니다.

알라딘: 클린 코드 Clean Code (aladin.co.kr)

클린 코드 Clean Code

※ 이번 장은 Args라는 클래스를 1차 초안으로 작성하고, 점진적으로 개선해나가는 과정을 소개합니다.
코드의 양이 너무 방대하여 개선하는 과정은 책을 통해 확인해주신다면 감사하겠습니다.

점진적인 개선

• 프로그래밍은 과학보다는 공예에 가깝다.
• 깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다.
• 무조건 돌아가는 프로그램을 목표로 잡고 프로그램이 돌아가면 다음 업무로 넘어가는 방식은 매우 좋지 않다.

1차 초안

• 누구도 처음부터 지저분한 코드를 짜려는 생각은 없었을 것이다. 하지만 어느 순간 프로그램은 손을 벗어나기 시작한다.
• 기능을 추가할수록 코드가 통제를 벗어나기 시작한다면 일단 멈추고 리펙터링을 시작하라.

점진적으로 개선하라

• 프로그램을 망치는 가장 좋은 방법 중 하나는 개선이라는 이름 아래 구조를 크게 뒤집는 행위이다.
• 테스트 주도 개발 (TDD) 기법을 사용하자.
• TDD는 언제 어느 때라도 시스템이 돌아가야 한다는 원칙을 따른다. 
• TDD는 시스템을 망가뜨리는 변경을 허용하지 않는다.
• 변경 전/후에 시스템이 똑같이 돌아간다는 사실을 확인하려면 언제든 실행이 가능한 자동화된 테스트 슈트가 필요하다.
• 시스템에 자잘한 변경을 가하고, 실패하는 테스트 케이스들로부터 문제점을 찾아 해결하고 다음 변경을 가하다보면 코드는 점점 깨끗해진다.
• 리펙터링을 하다보면 코드를 넣었다 뺐다 하는 사례가 아주 흔하다. 단계적으로 조금씩 변경하며 매번 테스트를 돌려야 하므로 코드를 여기저기 옮길 일이 많아진다.
• 소프트웨어 설계는 분할만 잘해도 품질이 크게 높아진다. (적절한 장소를 만들어 코드만 분리해도 설계가 좋아진다. 관심사를 분리하면 코드를 이해하고 보수하기 훨씬 더 쉬워진다.)

정리

• 그저 돌아가는 코드만으로는 부족하다. 돌아가는 코드가 심하게 망가지는 사례는 흔하다.
• 나쁜 코드보다 더 오랫동안 심각하게 개발 프로젝트에 악영향을 미치는 요인도 없다.
• 나쁜 코드도 깨끗한 코드로 개선할 수 있다. 하지만 비용이 엄청나게 많이 든다.
• 반면 처음부터 코드를 깨끗하게 유지하기란 상대적으로 쉽다.
• 그러므로 코드는 언제나 최대한 깔끔하고 단순하게 정리하자.