겉으로 보이는 동작은 그대로 둔 채, 코드를 이해하고 고치기 쉽게 내부 구조를 바꾸는 일. 기능을 더하는 일이 아니라 다음 변경을 덜 위험하게 만드는 정리다.
- 작은 단계: 한 번에 하나의 기법만 적용하고 매번 테스트한다. "리팩터링하다가 며칠 동안 코드가 깨졌다"면 그건 리팩터링이 아니라 재작성에 가깝다
- 두 개의 모자(Two Hats): 기능 추가 모자를 쓸 때는 구조를 건드리지 않고, 리팩터링 모자를 쓸 때는 기능을 더하지 않는다. 지금 어느 모자를 쓰고 있는지 의식한다
- 언제: 기능을 추가하기 직전(준비를 위한 리팩터링(Preparatory Refactoring)), 코드를 이해하려 할 때(이해를 위한 리팩터링(Comprehension Refactoring)), 지나가다 눈에 띌 때(쓰레기 줍기(Litter-Pickup Refactoring)). 세 번째 중복이 보이면 한다는 3의 법칙도 기준이 된다
- 하지 않을 때: 앞으로 고칠 일이 없는 코드, 처음부터 다시 쓰는 편이 쉬운 코드
- 이유는 경제성: 깔끔함이라는 도덕이 아니라, 개발 속도를 유지하려고 한다. 기술 부채를 갚는 주된 수단이다
- 안전망: 자가 테스트 코드가 있어야 마음 놓고 할 수 있다
성능과는 긴장 관계가 있다. 리팩터링 직후 조금 느려질 수 있지만 잘 정리된 코드가 튜닝하기도 쉽다. 측정 없이 추측으로 최적화하지 않는다(섣부른 최적화).
냄새를 찾는 어휘는 코드 냄새, 기법 목록은 리팩터링 기법 카탈로그에 있다. 켄트 벡은 구조 변경 중에서도 더 작고 안전한 단위를 정리(Tidying)라고 따로 부른다.
출처: 『리팩터링 2판』 마틴 파울러 (원서 Refactoring, 2nd Edition) · Martin Fowler: Definition Of Refactoring · Refactoring.Guru: When to Refactor