코드를 더 쉽게 이해하고 유지보수할 수 있도록 만드는 것이 리팩터링의 목적이다. 리팩터링을 진행하는 적절한 시점과 방법을 이해하면, 코드 품질을 높이고 개발 속도를 향상시킬 수 있다.
[!TIP] 3의 법칙 돈 로버츠(Don Roberts)가 제시한 가이드에 따르면, 리팩터링을 진행할 타이밍은 다음과 같다.
- 처음에는 그냥 한다.
- 비슷한 작업을 두 번째로 수행할 때는 계속 진행한다.
- 세 번째 반복이 발생하면 리팩터링을 진행한다.
기능을 추가하기 직전, 현재 코드베이스를 살펴보고 구조를 변경하면 도움이 되는 부분을 찾는다.
- 중복 코드 발생 시 "함수 매개변수화하기" 기법을 적용하여 유지보수를 용이하게 한다.
- 버그 수정 시, 오류 발생 코드를 하나로 합치는 방식이 유리하다.
코드를 수정하려면 먼저 코드의 동작을 파악해야 한다.
- 조건부 로직의 구조가 이상하거나, 함수명이 적절하지 않은 경우 리팩터링을 통해 명확성을 높인다.
- 리팩터링을 수행하면 코드에 대한 이해도를 더 깊게 만들 수 있다.
Important
"리팩터링하면 머리로 이해한 것을 코드에 옮겨 담을 수 있다. 그런 다음 수정한 코드를 테스트해보면 내 생각이 맞았는지 확인할 수 있다." - 위드 커닝햄(Ward Cunningham)
코드를 분석하는 과정에서 비효율적인 구조를 발견하는 경우가 많다.
- 불필요한 복잡성, 불필요한 반복이 있는 경우 간단한 수정으로 개선할 수 있다.
- 즉시 해결이 어렵다면
TODO:와 같은 코멘트를 남겨 이후 작업을 대비한다. - 캠핑 규칙(항상 처음 왔을 때보다 깔끔하게 정리하고 떠나자)을 적용한다.
리팩터링은 프로그래밍 과정에 자연스럽게 녹아 있어야 한다.
- 기능을 추가하거나 버그를 수정하는 동안 리팩터링을 함께 진행한다.
- 코드베이스 개선이 필요하다면 계획적인 리팩터링도 고려한다.
- 뛰어난 개발자는 새로운 기능을 쉽게 추가할 수 있도록 기존 코드를 수정하는 것이 최적의 접근 방식임을 이해한다.
리팩터링은 대부분 짧은 시간 안에 끝나지만, 대규모 리팩터링이 필요한 경우도 있다.
- 라이브러리 교체, 코드 공유를 위한 컴포넌트 분리 등은 몇 주가 걸릴 수도 있다.
- 팀 전체가 리팩터링에 매달려야 하는 경우, 당장 진행이 필요한지 신중하게 판단해야 한다.
- 추상 인터페이스를 활용하면 기존 코드와 새로운 라이브러리를 병행할 수 있어 리팩터링이 쉬워진다.
정기적인 코드 리뷰는 팀의 코드 품질을 높이는 데 기여한다.
- 코드 리뷰는 팀 전체의 지식 공유, 경험 전수, 코드 유지보수 등에 도움을 준다.
- 리팩터링을 통해 코드 리뷰 시 개선할 사항을 쉽게 적용할 수 있다.
- 코드 작성자가 직접 참여하는 리뷰를 진행하면 변경 의도를 명확하게 전달할 수 있다.
모든 경우에 리팩터링이 필요하지는 않다.
- 외부 API를 다루듯 호출해서 사용하는 코드의 경우, 내부 동작을 이해해야 할 시점까지 리팩터링을 미룬다.
- 리팩터링보다 처음부터 다시 개발하는 것이 나은 경우가 있을 수 있다. 하지만, 경험 없이는 판단하기 어렵기 때문에 직접 리팩터링을 시도해보는 것이 좋다.
link: External reference
author note: Related note in this repo