리팩토링: 소프트웨어 내부 설계를 더 높은 수준으로 진화시키는 것

개발자들이 리팩토링을 할까고민하지만, 언제 리팩토링을 하는게 좋은지에 대해서는 이야기 하지 않습니다.

새로운 기능을 추가하는 새 코드 단계와 그 코드를 깔끔하게 만드는 리팩토링 단계 → 왜 2단계로 나눌까?

• 리팩토링 단계에서 버그를 발견하더라도 그 것을 고치지 못한다

리팩토링의 종류

1. 쓰레기 줍기 리팩토링: 기존에 있던 쓰레기 코드를 리팩토링하기
2. 이해하기 위한 리팩토링: 말그대로

→ 둘이 “역겨운 코드”라는 점에서 비슷하다

• 두 경우를 직면했을 때 리팩토링을 하는 방법
  1. 지금 당장 고쳐야할까?
  2. 고치는데 얼마나 시간이 걸릴까? 즉, 내가 지금 하고 있는 일에 영향을 받지 않고, 쉽고 빠르게 고칠 수 있는건가?
     1. 네임 수정과 같은 리팩토링은 바로 해야한다. 그라고 내가 지금 하고 있는 작업에서 방해한다? 즉, 테스트 코드가 빨간색으로 나온다면 즉시 리팩토링을 해야한다.
     2. 즉시 리팩토링을 하지 않아도 되거나 할 수 없다면, 메모한다 그리고 나의 현재 작업을 끝낸다.
     3. 나의 현재 새 기능 작업(feat)이 끝나면 그 때 메모해둔 리팩토링을 한다.
  • 리팩토링을 해야하는 시점을 잘 정하는 것이 제일 중요하다. 리팩토링을 해야하는 시점을 정하는 가장 좋은 방법은 리팩토링을하는 적절한 범위를 정하는 것(리팩토링을 개별 테스크로 나누기)이다. ⭐️

1. 준비를 위한 리팩토링: 어제 관찮아보였던 코드가 오늘 기능 추가하면서 이상해보일떄
   1. 이 리팩토링을 먼저하면, 새로운 기능을 추가할 때, 더 빠른 속도로 개발할 수 있다.
2. 기획된 리팩토링(TTD 리팩토링): 프로젝트 전체 기획에 리팩토링이 껴있는 것
   1. 장점: 리팩토링을 할 시점이 명확하다
   2. 단점: 리팩토링을 해야하는 이유를 찾게 된다
   3. 역량이 좋은 팀에서는 하지 않는다, 왜냐면 그때 그때 리팩토링을 한다.
3. 장기적 리팩토링: 복잡한 모듈과 많이 꼬인 코드를 팀과 상의하고 나아갈 방향(수정 방법)을 정하고 새로운 기능을 추가하면서 조금씩 수정하는 리팩토링(리팩토링의 핵심 → 조금씩, 이전보다 더 나은 코드로 만드는게 목표)

리팩토링이 중요한 이유: 소프트웨어 설계에 신경을 쓰지 않으면 시간이 갈수록, 개발 속도가 떨어진다. 새 기능을 추사할 때마다, 복잡한 코드를 파악하느라 오랜 시간이 걸린다.