Chapter 2
2.1 리팩토링 정의
특정한 방식에 따라 코드를 정리하는 것이 리팩토링이지 단순히 코드를 정리하는 작업은 리팩토링이 아니다.
리팩토링은 성능 최적화와 비슷하며 둘 다 코드를 변경하지만 프로그램의 전반적인 기능은 그대로 유지한다.
단, 성능 최적화는 속도 개선을 리팩토링은 코드를 이해하고 수정하기 쉽게 만드는데 그 목적이 있다.
2.2 두개의 모자
기능을 추가 할 때는 기존 코드는 건드리지 않고 새 기능을 추가한다. 이때의 진척도는 테스트를 추가해 통과하는지 확인한다.
리팩토링할 때는 기능 추가는 하지 않고 오로지 코드 재구성에만 전념한다.
2.3 리팩토링 하는 이유
소프트웨어 설계가 좋아진다.
같은 일을 하더라도 설계가 나쁘면 코드가 길어지며 아키텍쳐가 무너진다.
코드량이 줄어든다고 시스템이 빨라지는 것은 아니나, 사람이 수정하는데 들여야하는 노력은 줄어든다.
이해햐야 할 코드가 짧을 수록 실수 없이 수정할 수 있다.
리팩토링하면 소프트웨어를 이해하기 쉬워진다.
프로그램을 동작하는데에만 신경쓰면 다른 개발자는 그 코드를 제대로 이해하기 어려워진다. (보통 '나'의 기억용량을 초과해 내가 그 수혜를 입게 된다.)
리팩토링하면 버그를 쉽게 찾을 수 있다.
코드를 이해하기 쉽다는 말은 버그를 찾기 쉽다는 말과 일맥상통한다.
리팩토링하면 프로그래밍 속도를 높일 수 있다.
좋은 설계는 기능 누적에 따라 그 진가가 드러난다.
2.4 언제 리팩토링 해야 할까?
준비를 위한 리팩토링 : 기능을 새로 추가하기 직전에 리팩토링한다.
이해를 위한 리팩토링 : 코드를 분석하며 리팩토링한다.
쓰레기 줍기 리팩토링 : 간단히 수정할 수 있는 것은 즉시 고치고, 시간이 좀 걸리는 일은 하던 일을 끝내고 나서 리팩토링한다.
수시로 하는 리팩토링
오래 걸리는 리팩토링 : 주어진 문제를 몇 주에 걸쳐 조금씩 해결해 가는게 효과적이다.
코드 리뷰에 리팩토링 활용하기
리팩토링하지 말아야 할 때
- 외부 API 다루듯 호출해서 쓰는 코드라면 내부 동작을 이해해야 할 시점에 리팩토링해야 효과를 볼 수 있다.
- 처음부터 새로 작성하는게 쉬울 때에도 리팩토링 하지 않는다.
2.5 리팩토링시 고려할 문제
리팩토링은 개발 기간을 단축하고, 기능 추가 시간을 줄이고, 버그 수정 시간을 줄이기 위한 경제적인 이유로 하는 것이다.
좋은 설계는 지향해야 하지만 클린코드에 집착하지 말자, 클린코드가 리팩터링의 궁극적인 목적이 되어서는 안된다
새 기능 개발 속도 저하
리팩토링이 당장의 속도 저하를 일으키는 것처럼 보일 수 있고 이것이 실전에서 적용하는데 가장 큰 걸림돌이다.
지속적인 코드베이스 개선을 통해 생산성을 키우도록 해야 한다.
코드 소유권
코드 소유권이 나뉘어 있거나 API 자체일 경우 리팩토링에 제약이 있지만 리팩토링이 가능하다.
브랜치
독립 브랜치로 작업하는 기간이 길어질수록 마스터로 통합하기가 어려워진다.
브랜치 통합 주기를 짧게해 머지 시 복잡도를 줄이는 것은 리팩토링에도 도움이 된다.
테스팅
레거시 코드
데이터베이스
2.6 리팩토링, 아키텍쳐, 애그니(YAGNI)
리팩토링이 아키텍처에 미치는 실질적인 효과는 요구사항 변화에 자연스럽게 대응하도록 코드베이스를 잘 설계해준다는 것이다.
현재까지 파악한 요구사항만을 해결하는 소프트웨어를 구축하고, 진행하면서 아키텍처도 그에 맞게 리팩토링해서 바꾼다.
