🔶언제 리팩터링해야 할까?

🔹 1. "3의 법칙"

1. 처음에는 그냥 한다.
2. 비슷한 일을 두 번째로 하게 되면(중복이 생겼다는 사실에 당황스럽겠지만), 일단 계속 진행한다.
3. 비슷한 일을 세 번째 하게 되면 리팩터링한다.

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

리팩터링하기 가장 좋은 시점은 코드베이스에 기능을 새로 추가하기 직전이다.
이 시점에 현재 코드를 살펴보면서 구조를 살짝 바꾸면 다른 작업을 하기가 훨씬 쉬워질 만한 부분을 찾는다.
중복되는 코드가 많아지면 유지 보수성이 떨어진다. 수정 사항이 발생하면 모든 중복되는 부분을 찾아 전부 수정해야한다. 이런 경우에는 함수 매개변수화하기 방법을 적용한다. 그러면 그 함수에 필요한 매개변수를 지정해서 호출하기만 하면 된다.
버그를 잡을 때도 중복된 코드를 하나로 합쳐두면 작업하기도 편하고 버그가 수정된 상태가 오래 지속될 가능성이 높다. 동시에 같은 곳에서 다른 버그가 발생할 가능성을 줄일 수도 있다.

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

코드를 수정하려면 먼저 해당 코드가 하는 일을 파악해야된다. 코드의 의도가 더 명확하게 드러나도록 리팩터링 할 여지는 없는지 찾아본다.(ex. 함수 이름)
코드에 대해 이해한 내용을 리팩토링을 통해 머리로 이해한 것을 코드에 반영시키고 테스트를 통해 확인한다.
함수와 변수의 이름을 적절하게 변경하고 긴 함수를 잘게 나누다보면 이전에 보이지 않던 설계가 눈에 들어온다.

🔹 4. 쓰레기 줍기 리팩터링

코드를 파악하는 중 비효율적인 코드를 발견할 때가 있다. 예를 들어 로직이 필요 이상으로 복잡하거나, 매개변수화한 함수 하나면 될 일을 거의 똑같은 함수 여러 개로 작성해놨을 수 있다. 하지만 원래 하려던 작업을 하는 시간을 너무 많이 뺐을 수 없으니 간단한 것은 즉시 수정하고 시간이 걸리는 일은 일이 끝난 이후에 처리하는 것을 쓰레기 줍기 리팩터링이라고 한다.
리팩터링은 작업을 나누어 진행해도 코드가 깨지지 않도록 해야된다.

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

4번까지의 리팩터링은 모두 기회가 될 때 진행한다. 리팩터링은 일정을 따로 잡아두지 않고 기능 추가나 버그를 잡는 동안 함께 진행한다. 언제 리팩터링을 하던 눈앞의 문제뿐 아니라 앞으로 할 작업에도 도움을 준다.
리팩터링은 프로그래밍과 구분되는 별개의 활동이 아니다.
리팩터링은 코드 품질에 상관없이 보기 안 좋은 코드, 잘 작성된 코드 전부 진행해야 된다. 상황에 따라 리팩터링을 해야되는 기준이 변경될 수 있기 때문이다.
무언가 수정하려 할 때는 먼저 수정하기 쉽게 정돈하고 그런 다음 쉽게 수정한다.
개발 과정에서 계획적인 리팩터링을 할 경우 무조건 나쁜 것은 아니지만 그동안 문제가 심각해질 수 있기 때문에 계획된 리팩터링을 최소화하고 상시 리팩터링을 많이 해야 된다.

🔹 6. 오래 걸리는 리팩터링

리팩터링은 대부분 긴 시간이 필요하지 않지만 라이브러리 교체, 일부 코드를 컴포넌트로 추출과 같은 대규모 작업도 있다. 이러한 경우 모든 팀원이 전부 리팩터링에 참여하는 것이 아닌 누구든지 리팩터링해야할 코드와 관련한 작업을 하게 될 때마다 원하는 방향으로 조금씩 개선하는 식이다.
리팩터링은 코드를 깨트리지 않는다는 장점을 이용하는 것이다.

🔹 7. 코드 리뷰에 리팩터링 활용하기

코드 리뷰 중 리팩터링이 가능한지 생각해 보고 쉬운 경우에는 바로 진행한다. 이러한 과정을 반복하면 코드로 직접 아이디어를 확인할 수 있다.
리팩터링은 코드 리뷰의 결과를 더 구체적으로 도출하는 데에도 도움 된다. 개선안들을 제시하는데 그치지 않고 직접 구현해 볼 수 있기 때문이다.
리팩터링을 잘 접목할 수 있는 코드 리뷰 방법은 Pair Programming이다. Pull-Request 방법의 경우 코드 작성자가 코드 검토 과정에 참여하지 않기 때문이다.
Pair Programming의 경우 작성자와 검토자가 같이 코드를 보기 때문에 리팩터링에 훨씬 효과적이다.

🔹 8. 관리자에게는 뭐라고 말해야 할까?

관리자는 리팩터링을 "누적된 오류를 잡는 일, 가치 있는 기능을 만들어내지 못하는 작업"이라고 오해하는 경우가 있다.
개발자의 역할은 효과적은 소프트웨어를 최대한 빨리 만드는 것이다. 리팩터링은 소프트웨어 개발 시간을 단축시키는데 효과적이기 때문에 필수적이다.

🔹 9. 리팩터링하지 말아야 할 때

지저분한 코드가 있더라도 굳이 수정할 필요가 없다면 리팩터링 하지 않는다.
외부 API처럼 호출해서 사용하는 코드라면 지저분해도 그냥 둔다.
내부 동작을 이해해야 할 시점에 리팩터링해야 효과를 제대로 볼 수 있다.
리팩터링하는 것보다 처음부터 새로 작성하는 것이 쉬울 때도 리팩터링 하지 않는다. 하지만 이것은 해보기 전까지 어느 것이 더 쉬운지 알기 어렵기 때문에 결정을 내리기 쉽지 않다.