• 목차
  • 1. 리팩터링 정의
  • 2. 두개의 모자
  • 3. 리팩터링 하는 이유
  • 4. 언제 리팩터링 해야할까?
  • 5. 리팩터링 시 고려할 문제
  • 6. 애그니(YAGNI)
  • 7. 나의 회고
  • 8. 러버덕

리팩터링 정의

• [명사] 소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법
• [동사] 소프트웨어의 겉보기 동작은 그대로 유지한 채, 여러 가지 리팩터링 기법을 적용해서 소프트웨어를 재구성하다

두 개의 모자

• 소프트웨어 개발 목적은 크게 두가지 이다. ‘기능 추가’ or ‘리팩터링’

✨기능추가 모자

• ‘기능 추가’ 모자를 쓴 다음은 기존 코드는 절대 건드리지 않고 only 새 기능만 추가한다.
• 진척도는 테스트를 추가해서 통과하는지 확인하는 방식으로 측정

✨리팩터링 모자

• ‘리팩터링’ 모자를 쓴 다음은 기능 추가는 절대 하지 않고 오로지 코드 재구성에만 전념한다. (놓친 테스트케이스를 발견하지 않는 한)
• 테스트도 새로 만들지 않는다.
• 이 두개의 모자를 자주 바꿔가면서 작업하며, 내가 쓰고 있는 모자가 무엇이고, 미묘한 작업 방식의 차이를 인식하자

리팩터링 하는 이유

• 소프트웨어 설계가 좋아진다. (코드로 설계를 파악하기 쉽고, 중복 코드가 제거되어 코드량이 줄어든다.)
• 소프트웨어를 이해하기 쉬워진다. (코드의 목적이 잘 들어나서, 내 의도를 더 명확하게 전달 가능)
• ✨버그를 쉽게 찾을 수 있다.
• ✨프로그래밍 속도를 높일 수 있다. (새로운 기능을 추가할수록 새 코드를 기존 코드베이스에 녹여낼 방법을 찾는데 걸리는 시간이 늘어난다 > 지구력 가설(내부 설계에 심혈을 기울이면, 소프트웨어의 지구력이 높아져 빠르게 개발할 수 있는 생태를 더 오래 지속할 수 있다.)

언제 리팩터링 해야할까?

• 3의 법칙 (처음에는 그냥 하고, 비슷한 일을 3번하게되면 리팩터링 한다.)
• 준비를 위한 리팩터링 : 기능을 쉽게 추가하게 만들기
• 이해를 위한 리팩터링 : 코드를 이해하기 쉽게 만들기
• 쓰레기 줍기 리팩터링
• ✨계획된 리팩터링과 수시로 하는 리팩터링 (보기 싫은 코드를 발견하면 리팩터링하자
• ✨코드리뷰에 리팩터링 활용하기

리팩터링 시 고려할 문제

• 새 기능 개발 속도 저하 : 궁극적으로 리팩터링은 개발 속도를 높여, 더 적은 노력으로 더 많은 가치를 창출하는 것
• 코드 소유권 : 팀 내에서 코드를 한 사람이 소유하지말고 러프하게 ‘팀’으로서 소유할 것
• 브랜치 : 지속적 통합(CI)을 통해 머지의 복잡도를 줄이자. CI + 리팩터링 = 익스트림 프로그래밍(XD)
• ✨✨테스팅 : 리팩터링 과정에서 버그가 생기지 않았을까 하는 불안감을 없애자. > 테스트 + 리팩터링 = TDD
• 레거시 코드

애그니(YAGNI)

• you aren’t going to need it : 너는 필요 없을거야!
• 예상되는 변경을 미리 반영하지 말고, 현재에 필요한 기능만 개발하자.

나의 회고 🤔

그동안 내가 리팩터링을 한 시점은 ‘마음에 들지 않는 코드를 발견했을 때’, ‘코드 리뷰를 받을 때’ 가 주로 해당되어 왔다.

하지만 책을 읽어보니 위의 두가지 경우도 활용하면서, 의도적으로 개발할 때 리팩터링을 하는 시간을 가지면 좋겠다는 생각이 들었다. (50분 기능 개발, 10분 리팩터링)

기능 개발 모자와 리팩터링 모자도 인상 깊었는데, 두 가지 내용의 커밋이 제대로 분리될 수 있도록 신경써야겠다.

또한 테스트의 중요성에 대한 강조가 많은데, 테스트를 활용한 개발을 직접 해본적이 없어서, 테스트 케이스 작성하느라 더 시간이 오래 걸릴까?하는 생각이 들었다. 궁극적으로 봤을 때는 개발 속도가 향상된다고 하니 뭅스터 프로젝트에서 직접 적용하면서 체험해 봐야겠다.

앞으로 리팩터링 책을 읽으면서 배우는 리팩터링 기법들은 뭅스터 서버 코드에 활용하면서 적용해보고자 한다.

적합한 예시가 있을 경우도 포스팅을 추가할 예정이다.

러버덕🏃‍♂️

CI가 왜 리팩터링에 좋나?

• 머지의 복잡도를 줄인다.
• 변경된 것으로 바로 적용해서 사용할 수 있다.

CI는 머지 복잡도를 낮춰주는데 브랜치 전략을 사용하지 않는 거나 다름없지 않나?

• 기능별 브랜치는 며칠간 유지되는지 알 수 없고 통합 주기가 2~3일인 것으로 1일로 줄이는 것이다.
• 기능별 브랜치를 머지하고 반드시 삭제하지는 않아도 된다. 여러 번 머지해도 된다.

리팩터링과 성능

• 큰 기능을 잘게 나누어 함수화하고 각 기능별(함수별)로 성능 측정을 더 빨리 할 수 있어서 성능 튜닝이 편해진다.
• 함수화하는 시간이 너무 오래걸릴 것 같아서 크게 구현해놓고 나중으로 미룰 것 같다.
• 함수화하면 기능 하나마다 가독성이 올라간다.
• 함수는 재사용성이 필수적이라고 생각해서 나누지 않는다.
• 함수 분리 → TDD → 리팩터링

리스트럭쳐링과 리팩터링

• 리스트럭쳐링은 구조를 바꾸는 것이라 성능 튜닝에 가깝다고 생각한다.
• 리팩터링은 겉보기 동작 유지되면서 구조가 바뀌는 것이다.

리팩터링 자동화 도구 vscode에서는 뭐가 있는지?

• command + f를 쓴다..
• CI,CD가 되어야 한다.. 지금 수준에서 하기 힘들다.
• Prettier, ESLint도 일부 지원하고 있다.*