리팩터링에 대한 진실

누군가 “리팩터링하다가 코드가 깨져서 며칠이나 고생했다”라고 한다면, 십중팔구 리팩터링한 것이 아니다.

• 코드베이스를 정리하거나 구조를 바꾸는 모든 작업을 재구성이라는 포괄적인 용어로 표현하고,
• 리팩터링은 재구성 중 특수한 한 형태로 본다.
• 즉, 코드를 정리하는 모든 작업을 모두 리팩터링이라 하는 게 아니라, 1장에서 제시한 특정한 정의에 따라 코드를 정리하는 것이 리팩토링이다.
• 리팩터링은 시간을 일정에 따로 잡아두지 않고, 대부분의 리팩터링을 다른 일을 하는 중에 처리한다.
• 보기 싫은 코드를 리팩터링하자. 그런데 잘 작성된 코드 역시 수많은 리팩터링을 거쳐야 한다.

리팩터링 vs 성능 최적화

• 리팩터링의 목적은 코드를 이해하고 수정하기 쉽게 만드는 것이다.
• 프로그램 성능은 좋아질 수도, 나빠질 수도 있다.
• 반면 성능 최적화는 오로지 속도 개선에만 신경 쓴다.
• 그래서 목표 성능에 반드시 도달해야 한다면 코드는 다루기에 더 어렵게 바뀔 수도 있음을 각오해야 한다.

리팩터링 장점

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

  • 리팩터링을 하면 중복 코드를 제거하고 코드량이 줄어들면 이해하고 수정하는 데 드는 노력도 줄어든다.

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

  • 내 의도를 더 명확하게 전달하고 코드가 더 잘 읽히게 도와준다.
  • 이건 다른 사람을 배려하기 위함도 있지만 코드를 머리에 모두 담아두지 않는 이상 내가 다른 사람이 될 수도 있다는 사실을 명심하자.

• 버그를 쉽게 찾을 수 있다.

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

  

리팩터링 3의 법칙

1. 처음에는 그냥 코드를 짠다.
2. 비슷한 일을 두 번째로 하게 되면 일단 계속 진행한다.
3. 비슷한 일을 세 번째 하게 되면 리팩터링한다.

리팩터링하지 말아야 할 때

리팩터링은 무조건 해야한다기 보단 상황에 맞게 해야 한다. 지저분한 코드를 발견해도 다음과 같은 상황이라면 굳이 수정하지 않는다.

• 외부 API 다루듯 호출해서 쓰는 코드.
  • 내부 동작을 이해해야 할 시점에 리팩터링을 해야 효과를 제대로 볼 수 있다.
• 리팩터링하는 것보다 처음부터 새로 작성하는 게 쉬울 때.