[개발자 책읽기] 클린 코드-애자일 소프트웨어 장인 정신 (14장-점진적인 개선)

해당 글은 Robert C.Martin 클린 코드 라는 책을 읽고 학습한 내용을 정리 및 회고하는 글 입니다. 자세한 사항은 YES 24 클린 코드 - 애자일 소프트웨어 장인 정신 에서 확인해주세요.

 

클린 코드 - 애자일 소프트웨어 장인 정신 (Uncle Bob)

 

• 위키북스
• 지은이: Robert C.Martin (Uncle Bob)
• 옮긴이: 박재호, 이해영

 

 

---

 

이번 장에서 이야기하고자 하는 것

 

이번 장에서는 Command Line 의 Argument 를 분석하는 유틸리티를 만들며 이를 점직적으로 개선하는 방안을 이야기한다.

 

점진적으로 개선하다

 

• 프로그램을 망치는 가장 좋은 방법중 하나는 개선이라는 이름 아래 구조를 크게 뒤집는 행위이다
• TDD 를 해아하는 또 다른 이유가 추가된다
  • 바로 TDD는 어느 때라도 시스템이 돌아가야 한다는 원칙 때문에
  • 또한 테스트는 항상 실행이 가능해야 하고 잘 돌아가야 한다는 원칙도 추가
• 가능한 코드를 최소한으로 수정하고 단순한 변경을 가하자

 

테스트는 계속해서 통과한다

 

• 어떠한 변경이더라도 테스트는 계속해서 성공해야 하고 실행 가능해야 한다
  • 리팩토링과 테스트는 계속해서 병행되어야 한다.

 

돌아가는 코드에 만족하는 것은 전문성이 부족한 개발자다

• 나쁜 코드가 유지보수에 가장 큰 악이다.
  • 나쁜 요구사항은 다시 정의하면 된다
  • 나쁜 일정은 다시 짜면 된다
  • 나쁜 팀 역한은 복구하면 된다.
  • 나쁜 코드는 썩어 문드러진다
• 아침에 엉망으로 만든 코드를 오후에 정리하기란 어렵지 않다. 더욱이 5분 전에 엉망으로 만든 코드는 지금 당장 정리하기 아주 쉽다.

나의 해석과 회고

 

이번 장에서는 Args 를 분석하는 유틸리티를 만들어보며 점진적인 개선이란 무엇인가를 생각할 수 있게 한다.

 

내가 이번 장에서 느낀 점은 다음과 같다.

 

1. 개념을 쌓자
2. 테스트는 계속해서 성공시키자

 

개념을 쌓자

글의 내용 중에서 ArgumentMarshaler 에 대해서 처음에 "어? 이름을 뭐로 하지? 이게 맞나?" 하는 느낌으로 Naming 을 한다.

 

하지만 점점 ArgumentMarshaler 에 살을 붙혀나갈 수록 개념은 쌓여가며 완벽한 개념이 되는 것을 목격했다.

 

현재 사내에서도 어떤 객체와 협력해야 하는 대상의 역할이 모호할 때는 고민하는 것을 멈추고 __.class 혹은 XXX.class 라는 Naming 을 한다.

 

그리고 해당 객체에게 책임을 부여하고 해당 객체가 하는 일이 명확해질 때까지 개념을 쌓는다.

 

이렇게 개념을 쌓는다는 접근 방식에 대해서 나는 크게 와닿았고 역시 클린 코드에서도 이와 같은 상황을 마주했다.

 

테스트는 계속해서 성공시키자

이번 글을 읽으면서 나는 점진적으로 개선하기 == TDD 를 유지하기 라는 느낌을 많이 받았다.

 

어떠한 변경 사항에 있어서도 Uncle bob 은 테스트 코드를 실행하고 테스트를 성공시킨다.

 

계속해서 자잘한 변경에 대해서도 테스트를 실행하고 성공시키고.

 

이런 행위는 의도적인 수련이 필요한 것 같다

 

지금 돌아보면 나는 참 테스트 실행을 안 한다. 빌드를 하지 않는다.

 

이유는? 까먹는다. 이게 바로 의도적으로 수련을 해야 하는 이유가 아닐까 싶다

 

결국 여러 기능들의 변화에 따라 수정해야할, 통과시켜야 할 테스트는 쌓이게 되고 한 번 실패한 것을 놓치면 다시 개선을 하기 전으로 돌아가야 하는 상황을 참 많이 겼었다.