[리팩터링 2판] CHAPTER 02. 리팩터링 원칙 (2)

리팩터링 2판 책을 읽고 공부한 내용을 기록한다. 2판은 자바스크립트를 기반으로 예시를 제공하지만 저자 마틴 파울러는 리팩터링의 핵심 요소는 언어와 상관없이 동일하다고 이야기한다.

해당 기록에서는 책에서 다루는 예제 코드 대신 개인적으로 작성한 예제 코드를 사용한다. 즉, 책의 모든 내용과 순서를 그대로 담지 않을 수 있다.

각 장/절 별로 작성한 코드는 깃허브 개인 저장소에서 관리한다.

불릿 기호는 책의 내용 중 의미있다고 판단한 것을 옮겨 적은 것이다.

2장의 2.6절부터 2.11절까지 학습한 내용을 기록한다. 리팩터링 원칙에 대한 저자의 생각 중 공감되는 부분과 나의 의견을 함께 작성한다.

2.6 리팩터링, 아키텍처, 애그니(YAGNI)

• 리팩터링이 아키텍처에 미치는 실제적인 효과는 요구사항 변화에 자연스럽게 대응하도록 코드베이스를 잘 설계해준다는 데 있다.
• 유연성 메커니즘이 오히려 변화에 대응하는 능력을 떨어뜨릴 때가 대부분이다.
• 추측하지 않고, 그저 현재까지 파악한 요구사항만을 해결하는 소프트웨어를 구축한다.
• YAGNI(“you aren’t going to need it”): 당장에 필요한 기능만으로 최대한 간결하게 만들라

코드리뷰를 진행하다보면 많은 고민이 담겨있지만 꼭 필요한 방향이었을까 생각하게 만드는 코드가 있다. 아직 구체화되지 않은 요구사항까지(a.k.a. 먼 ~ 미래) 반영하여 범용적으로 작성한 코드가 그 중 하나이다. 이러한 코드는 오히려 이후 요구사항에 따라 설계를 변경해야 하는 경우를 방해할 수 있다. 그래서 나는 현재의 요구사항을 충실히 반영하고, 이후에는 필요성이 생길 때 리팩터링을 하는 방향을 선호한다.

이전에 작성한 [WHY 시리즈 1] E.012 — 두 번째 Pull Request 이야기 글의 불투명한 미래 섹션에서 비슷한 경우를 담고있다.

2.7 리팩터링과 소프트웨어 개발 프로세스

• 자가 테스트 코드, 지속적 통합, 리팩터링이라는 세 기법은 서로 강력한 상승효과를 발휘한다.

이 책에서는 테스트 코드가 리팩터링의 가장 중요한 토대라고 꾸준히 언급한다. 리팩터링한 코드가 의도하지 않은 문제를 발생시키지 않도록 반복적으로 점검을 하기 위해서다. 또한, 팀으로 개발을 진행할 때 각 팀원의 (리팩터링을 포함한) 작업을 서로 빠르게 공유할 수 있도록 지속적 통합의 필요성도 언급한다.

2.8 리팩터링과 성능

• 소프트웨어를 이해하기 쉽게 만들기 위해 속도가 느려지는 방향으로 수정하는 경우가 많다.
• 소프트웨어를 빠르게 만드는 비결은, 먼저 튜닝하기 쉽게 만들고 나서 원하는 속도가 나게끔 튜닝하는 것이다.
• 단기적으로 보면 리팩터링 단계에서는 성능이 느려질 수도 있다. 하지만 최적화 단계에서 코드를 튜닝하기 훨씬 쉬워지기 때문에 결국 더 빠른 소프트웨어를 얻게 된다.

저자는 코드를 직관적으로 설계하는 것(이해하기 쉬운 코드)과 성능 사이의 우선순위를 이야기한다. 코드를 이해하기 쉽게 만드는 것이 선행되어야 성능을 위한 작업도 수월해진다.

2.9절 ~ 2.11절은 리팩터링의 유래, 참고할만한 추가 자료 등을 언급해서 굳이 이 글에 정리하지 않았다.