[Clean Code] 14장 | 점진적인 개선

🚩 모듈을 개선하고 정리하는 방법

"프로그래밍은 과학보다 공예에 가깝다. 깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다." (p.254)

어떻게 짰느냐고?

• '돌아가는' 프로그램을 목표로 잡는 것은 자살행위다.
• 우아한 프로그램은 한 방에 뚝딱 만들어지지 않는다.

그래서 멈췄다

• 프로그램을 어떻게든 완성한 후가 아니라, 구조를 짤 수 있는 시점에 리팩토링을 시도한다.

점진적으로 개선하다

• 구조를 뒤집어 엎는 것은 위험부담이 크다.
• TDD 기법을 사용하자.
  • 변경에 무관하게 시스템이 똑같이 돌아가야 한다.
  • 자동화된 테스트 슈트를 작성하여 정상 작동을 보장한다.

결론

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

"아침에 엉망으로 만든 코드를 오후에 정리하기는 어렵지 않다.
더욱이 5분 전에 엉망으로 만든 코드는 지금 당장 정리하기 아주 쉽다." (p.321)

📝 느낀점

모듈과 클래스를 점진적으로 개선하는 방법의 예시를 보여준 챕터였다. 이렇게 작은 모듈을 정리하는 데에도 수 단계와 단위 테스트를 거쳐야 한다는 것을 간접적으로 배울 수 있었고, 그렇기 때문에 초반부터 좋은 코드를 유지하는 것의 중요성을 더 잘 느낄 수 있었다. 특히 setArgument 메소드와 ArgsException을 정리해내는 부분이 특히 인상깊었는데, 여러 타입의 인스턴스를 한 클래스에서 처리하는 방식으로 코드를 개선하는 방법을 잘 느낄 수 있었다. 지금 졸프 코드를 짜면서 계속 새로운 타입의 예외가 생기는데 그 때마다 새 exception 클래스를 생성하는 식으로 구현해놨다. 이런 식으로 각기 다른 에러를 던질 것이 아니라, 책에서 보여준 것처럼 에러 코드를 부여해서 CustomRuntimeException 클래스에서 한 번에 다 처리하는 방식으로 코드를 변경해야 겠다고 생각했다. 바로 이따 저녁에 구현을 해야겠다.