✏️2.4 언제 리팩터링해야 할까?
🎈 3의 법칙
처음에는 그냥 한다.
비슷한 일을 두 번째로 하게 되면, 알단 계속 한다.
비슷한 일을 세 번째 하게 되면 리팩터링한다.
🔗 준비를 위한 리팩터링: 기능을 쉽게 추가하게 만들기
리팩터링하기 가장 좋은 시점: 코드베이스에 기능을 새로 추가하기 직전
구조를 살짝 바꾸면 다른 작업을 하기가 훨씬 쉬어질 만한 부분을 찾아 중복 코드가 없게 함수 매개변수화하기를 적용해서 호출한다. 버그를 잡을 때도, 오류를 일으키는 코드가 세 곳에 복제되어 있다면, 한 곳으로 합치는 리팩터링으로 상황을 개선해 놓으면 버그가 수정된 상태가 오래 지속될 가능성을 높이면서 버그가 발생할 가능성을 줄인다.
🔗 이해를 위한 리팩터링: 코드를 이해하기 쉽게 만들기
코드의 의도가 더 명확하게 드러나도록 리팩터링할 여지가 없는지 찾아보자.
조건부 로직의 구조가 이상하지 않은지
함수의 이름을 잘못 정해서 실제로 하는 일을 파악하는 데 시간이 오래 걸리지는 않는지
수정한 코드를 테스트해보고, 이해한 것을 코드에 반영해두면 더 오래 보존하고, 동료들도 알 수 있다.
자잘한 세부 코드에 이해를 위한 리팩터링
어떤 역할을 하는지 이해된 변수는 적절한 이름으로 변경하기
긴 함수를 잘게 나누기
→ 코드가 깔끔하게 정리되어 전에는 보이지 않던 설계가 눈에 들어오기 시작한다.
🔗 쓰레기 줍기 리팩터링
일을 비효율적으로 처리하는 모습
로직이 쓸데없이 복잡한 경우
매개변수화한 함수 하나만 될 일을 함수 여러 개로 작성한 경우
→ 간단히 수정할 수 있는 것은 즉시 고치고, 시간이 걸리는 일은 짧은 메모만 남긴 다음, 하던 일을 끝내고 나서 처리한다.
🔗 계획된 리팩터링과 수시로 하는 리팩터링
리팩터링은 프로그래밍과 구분되는 별개의 활동이 아니다.
보기 싫은 코드를 발견하면 리팩터링하자. 그런데 잘 작성된 코드 역시 수많은 리팩터링을 거쳐야한다.
매개변수화하거나 개별함수로 나누는 기준을 정해 리팩터링한다.
뛰어난 개발자는 새 기능을 추가하기 쉽도록 코드를 수정하는 것이 그 기능을 가장 빠르게 추가하는 것임을 안다. 리팩터링 작업 대부분은 드러나지 않게 기회가 될 때마다 해야 한다.
❓버전 관리 시스템에서 리팩터링 커밋과 기능 추가 커밋을 분리해야 할까
리팩터링은 기능 추가와 밀접하게 엮인 경우가 너무 많기 때문에 굳이 시간 낭비일 수 있다. 팀에 적합한 방식을 실험을 통해 찾아내자.
🔗 오래 걸리는 리팩터링
오래 걸리는 리팩터링
라이브러리 새 것으로 교체
컴포넌트 분리
의존성 정리 작업
리팩터링이 코드를 깨트리지 않는다는 장점을 활용하자.
→ 일부를 변경해도 모든 기능이 항상 올바르게 동작한다. 라이브러리를 교체할 때, 기존 것과 새 것 모두를 포용하는 추상 인터페이스부터 마련하면 훨씬 쉽게 교체할 수 있다.
코드 리뷰에 리팩터링 활용하기
리팩터링은 다른 이의 코드를 리뷰하는데도 도움된다.
코드 리뷰의 결과를 더 구체적으로 도출하는데 도움된다.
풀 요청 모델(pull request model) 코드 작성자 없이 검토하는 방식에서는 효과적이지 않다.
짝 프로그래밍(pair programming) 코드 작성자와 나란히 앉아서 코드를 훑어가면서 리팩터링하는 것이 가장 좋은 방법이다.
관리자에게는 뭐라고 말해야 할까?
프로 개발자의 역할은 효과적인 소프트웨어를 최대한 빨리 만드는 것이다. 리팩터링하면 소프트웨어를 빠르게 만드는 데 아주 효과적이다. 새 함수를 추가하려는데 현재 설계가 적합하지 않다면 먼저 리팩터링하고 나서 함수를 추가하는 편이 빠르다.
프로 개발자에게 주어진 임무는 새로운 기능을 빠르게 구현 하는 것
→ 가장 빠른 방법은 리팩터링 하는 것
리팩터링하지 말아야 할 때
지저분한 코드를 발견해도 굳이 수정할 필요가 없는 경우
외부 API 다루듯 호출해서 쓰는 코드라면 지저분해도 그냥 둔다.
내부 동작을 이해해야 할 시점에 리팩터링해야 효과를 볼 수 있다.
리팩터링 하는 것보다 처음부터 새로 작성하는게 쉬운 경우
Last updated