리팩터링 정의
80p.
리팩터링의 목적은 코드를 이해하고 수정하기 쉽게 만드는 것이다. 그 과정에서 성능은 좋아질수도 나빠질수도 있다. 성능 최적화는 오로지 성능에만 집중한다. 리팩터링은 중간에 언제든지 멈추더라도 제 기능을 해야한다.
리팩터링하는 이유
81p ~ 84p.
- 리팩터링하면 소프트웨어 설계가 좋아진다. 중복 코드를 제거할 수 있기 때문이다.
- 소프트웨어를 이해하기 쉬워진다. 다른 누군가가 보더라도 파악이 쉬워야한다. 여기서 누군가는 미래의 나일 가능성이 매우 높다.
- 버그를 쉽게 찾을 수 있다.
- 프로그래밍 속도를 높일 수 있다. 기능 추가에 걸리는 시간이 단축되기 때문이다. 처음부터 좋은 설계는 없다. 리팩터링으로 완성도를 높일뿐.
언제 리팩터링해야 할까.
86p ~ 91p.
- 준비를 위한 리팩터링. 새로운 기능을 추가하기 전 혹은 디버깅을 하기 전 겹치는 부분을 함수화 한다.
- 이해를 위한 리팩터링. 세부적으로 코드를 파악한 뒤 이해한 부분을 리팩터링에 반영한다. 그러면 나중에 다시보거나 다른 사람이 보기에도 이해가 쉽다.
- 쓰레기 줍기 리팩터링. 로직이 쓸데없이 복잡하거나 매개변수화한 함수 하나면 될 일을 여러개로 작성해뒀을때 리팩터링한다.
- 리팩터링은 개발과정의 하나이기 때문에 따로 일정을 잡지 않고 수시로 하는것이 좋다.
- 코드 리뷰에 리팩터링 활용하기. 리팩터링은 다른 이의 코드를 리뷰하는데도 도움된다. 리팩터링은 코드 리뷰의 결과를 더 구체적으로 도출하는 데에도 도움이 된다. 가장 좋은 코드 리뷰를 통한 리팩터링은 짝 프로그래밍이다.
리팩터링 시 고려할 문제
92p ~ 99p.
- 새 기능 개발 속도 저하. 리팩터링의 궁극적인 목적은 개발 속도를 높여서, 더 적은 노력으로 더 많은 가치를 창출하는 것이다.
- 코드 소유권. 리팩터링이란 섹터를 칼로 나누듯 나눠 특정 부분만 하기가 쉽지 않다. 코드 소유권을 팀 단위로 정하여 각 팀원의 영역은 있되, 수정을 막지는 않도록 한다.
- 브랜치. 개발 과정에서 마스터를 브랜치로 머지하며 개발하는데 그치지 않고, 수시로 브랜치를 마스터로 푸시 해줘야 한다. 그래야 자잘한 리팩터링이 복잡한 integration 없이 쉽게 반영된다.
- 테스팅. 리팩터링하기 위해서는 세부 섹션을 분할하여 테스트할 수 있는 자가 테스트 코드가 필요하다.
- 레거시 코드. 테스트코드가 없는 레거시 코드는 리팩터링하기가 매우 힘든데, 테스트를 추가할 틈새를 찾아서 시스템을 테스트해야하고, 이때 틈새를 만드는 방법은 리팩터링이다. 이 리팩터링은 버그의 위험이 높지만 감수해야한다.
애그니(YAGNI)
101p.
아키텍쳐를 매우 견고히 설계하려다보면 너무 많은 요소를 미리 예상하여야한다. 이러한 대응이 오히려 유연성 매커니즘(매개변수 함수 등)이 오히려 변화에 대응하는 능력을 떨어뜨리기도 한다. You aren't going to need it, 현재 필요한 것을 착실히 리팩터링 하자.
성능과 리팩터링
105p ~ 106p.
보통 성능에 영향을 미치는 코드는 10% 정도이다. 90%의 코드를 성능개선을 위해 명료함을 버린다면, 굉장한 낭비가 된다. 그러므로 먼저 리팩터링을 하여 명료하게 만들고, 성능과 관련된 부분만 성능을 개선하는것이 좋다.
빠굥