2장에서는 리팩터링 전반에 적용된는 원칙을 이야기 하고 있다. 리팩터링의 정의부터 리팩터링을 어떤 자세로 해야하는지, 리팩터링을 하는 이유는 무엇인지, 리팩터링 시 고려해야 할 문제는 무엇인지 등을 이야기 하고 있다.

리팩터링의 정의

리팩터링: 소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법

• 이 때 겉보기 동작을 그대로 유지한다는 말의 뜻은 사용자 관전에서 달라지는 점이 없어야 한다는 것이다.
• 리팩터링의 목적은 코드를 이해하고 수정하기 쉽게 만드는 것이라서 프로그램 성능은 좋아질 수도, 나빠질 수도 있다. 즉, 성능 최적화와는 다른 것이다.

두 개의 모자

기능을 추가할 때는 '기능 추가'모자를 쓴 다음 기존 코드는 절대 건드리지 않고 새 기능을 추가하기만 한다.

리팩터링할 떄는 '리팩터링' 모자를 쓴 다음 기능 추가는 절대 하지 않기로 다짐한 뒤 오로지 코드 재구성에만 전념한다. 테스트도 새로 만들지 않는다.

내가 쓰고 있는 모자가 무엇인지와 그에 따른 미묘한 작업 방식의 차이를 분명하게 인식해야 한다.

• 나는 CO-KKIRI 프로젝트를 할 때 '기능 추가'와 '리팩터링'을 구분하지 않고, 내가 어떤 모자를 썼는지도 인식하지 않았는데 그 점을 반성하게 됐다.

리팩터링하는 이유

소프트웨어 설계가 좋아진다.

• 규칙적인 리팩터링은 코드의 구조를 지탱해줄 것이다.

소프트웨어를 이해하기 쉬워진다.

• 코드의 목적이 더 잘 드러나게 개선할 수 있다.

버그를 쉽게 찾을 수 있다.

• 프로그램의 구조를 명확하게 다듬으면 두루뭉술 했던 가정들이 분명히 드러난다.

프로그래밍 속도를 높일 수 있다.

• 모듈화가 잘 되어 있으면 전체 코드베이스 중 작은 일부만 이해하면 된다.

처음부터 좋은 설계를 마련하기란 매우 어렵다. 그래서 빠른 개발이라는 숭고한 목표를 달성하려면 리팩터링이 반드시 필요하다.

언제 리팩터링해야 할까?

준비를 위한 리팩터링: 기능을 쉽게 추가하게 만들기

• 리팩터링하기 가장 좋은 시점은 코드베이스에 기능을 새로 추가하기 직전이다.

이해를 위한 리팩터링: 코드를 이해하기 쉽게 만들기

• 내가 이해한 것을 코드에 반영해두면 더 오래 보존할 수 있을 뿐만 아니라 동료들도 알 수 있다.
• 즉, 코드를 분석할 때 리팩터링을 해보라는 뜻이다.

쓰레기 줍기 리팩터링

• 간단히 수정할 수 있는 것은 즉시 고치고, 시간이 좀 걸리는 일은 짧은 메모만 남긴 다음, 하던 일을 끝내고 나서 처리한다.
• 이해를 위한 리팩터링의 변형이다.
• 코드를 고치고 싶은데 일이 너무 커질까봐 손대지 못한 경험이 있다. 그래서 이 방법을 적극 이용하려고 한다.

계획된 리팩터링과 수시로 하는 리팩터링

• 리팩터링 작업 대부분은 드러나지 않게, 기회가 될 때마다 해야 한다.
• 리팩터링 커밋을 분리한다고 해서 무조건 좋은 것은 아님을 명심하고, 팀에 적합한 방식을 실험을 통해 찾아내자

오래 걸리는 리팩터링

• 라이브러리를 새것으로 교체하는 등의 대규모 리팩터링의 경우 팀 전체가 리팩터링에 매달리기 보다는 누구든지 리팩털이해야할 코드와 관련한 작업을 할 때마다 조금씩 개선하는 것을 추천한다.
• 라이브러리를 교체할 때는 기존 것과 새 것 모두를 포용하는 추상 인터페이스부터 마련해야 한다.

코드 리뷰에 리팩털이 활용하기

• 리팩터링은 코드 리뷰의 결과를 더 구체적으로 도출하는 데에 도움이 된다.

리팩터링하지 말아야 할 때

• 외부 API 다루듯 호출해서 쓰는 코드 처럼 굳이 수정할 필요가 없다면 리팩터링 하지 않고 내부 동작을 이해해야 할 시적에 리팩터링을 한다. 그래야 효과를 제대로 볼 수 있다.
• 리팩터링하는 것보다 처음부터 새로 작성한는 게 쉬울 때도 리팩터링하지 않는다.

리팩터링 시 고려할 문제

브랜치

• CI(Continuous Integration): 지속적 통합. CI에 따르면 모든 팀원이 하루에 최소 한 번은 마스터와 통합한다.
• 익스트림 프로그래밍(XP): 익스트림 프로그래밍은 애자일 방법론 중 하나로, 빠르게 변화하는 비즈니스 요구사항에 적합한 소프트웨어 개발 방법론으로 책에서는 CI와 리팩터링을 합쳐서 만든 것이라 한다.
• 책에서는 기능 브랜치 방식의 단점을 말하고 있고 기능브랜치 방식을 사용하더라도 브랜치 통합 주기는 짧아야 하며 CI를 적용하는 걸 추천하고 있다.