2장, 리팩터링 원칙

2021.09.13

리팩터링 정의

  • 소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법.
  • 소프트웨어의 겉보기 동작은 그대로 유지한 채, 여러가지 리팩터링 기법을 적용해서 소프트웨어를 재구성하는 방법.
  • 리팩터링은 성능상 변화가 생길 수 있지만 사용자관점에서는 달라지는 것이 없어야 한다.

소프트웨어를 개발할 때, 목적이 기능 추가리팩터링이냐를 분명히 두고 작업한다.

  • 기능 추가를 하는 경우에는 기존 코드를 절대 건드리지 않고 새 기능을 추가하자.
  • 리팩터링은 기능 추가를 절대하지 않고 오로지 코드 재구성에만 전념하자.

리팩터링을 하는 이유

  • 규칙적인 리팩터링은 코드의 구조를 지속적으로 지탱하여 좋은 아키텍처를 유지하게 해준다.
  • 리팩터링 과정 중 소프트웨어에 대한 이해력이 좋아지고 버그를 쉽게 찾을 수 있다는 장점이 있다.
  • 결과적으로, 소프트웨어의 좋은 아키텍처를 유지하기 위해.
    • 시간의 변화에 따른 기능 추가/변경 등을 원활하게 처리가 가능한 아키텍처

리팩터링하기 좋은 시점

  • 준비를 위한 리팩터링.

    • 기능을 새로 추가하기 직전.
  • 이해를 위한 리팩터링.

    • 코드의 의도가 명확하지 않은 경우.
    • 함수 이름이 이상. 조건부 로직이 이상.
  • 쓰레기 줍기 리팩터링.

    • 중복된 코드들 하나로 정리.
  • 위의 3가지 케이스는 프로그래밍 과정에서 자연스럽게 녹여서 진행한다.

    • 기능 추가/수정 개발, 버그 수정 등
  • 켄트백 : 무언가 수정하려 할 때는 먼저 수정하기 쉽게 정돈하고, 시작하자.

  • 오래걸리는 리팩터링.

    • 큰 라이브러리를 교체하는 대규모 리팩터링은 인터페이스 추상화를 통하여 구/신 라이브러리를 모두 호환하도록 준비하면 좋다.
  • 리팩터링하지 말아야 할 때.

    • 굳이 수정할 필요가 없는 코드는 하지 않아도 된다.
      • 기능 추가/수정이 없는 코드
      • 외부 API처럼 호출만 하여 사용되어지는 코드
    • 새로 작성하는게 더 효과적이라면 기존 코드를 리팩터링하지 않는다.

리팩터링시 고려할 문제

  • 리팩터링의 주목적은 개발기간을 단축시키는 것이고, 이를 명확하게 인지하고 있어야 한다.

    • 클린 코드, 코드의 심미성, 바람직한 엔지니어링 습관을 위해 하는 것이 아니다.
    • 코드 베이스를 이쁘게 하는 것이 목표가 아니라 경제적 이유로 하는 것입니다. 개발 기간을 줄이고, 기능 추가 시간과 버그 수정 시간을 줄이는 것이 중요합니다.
  • 데이터베이스 리팩터링은 프로덕션 환경에 여러 단계로 나누어 릴리즈하는 것이 좋다. -문제 발생시, 롤백이 편리하다.

리팩터링, 아키텍처, YAGNI ( You aren’t going to need it )

  • 코드 작성시, 당장에 필요한 기능만으로 최대한 간결하게!
  • 향후 변경에 유연하게 대처할 수 있는 유연성 메커니즘을 가지고 코드를 작성할 수 도 있다. ( 다만, 이 경우는 리팩터링을 미뤄서 나중에 훨씬 힘들어진다는 확신이 들때만 적용하는 것이 좋다. )
  • 리팩터링를 통해 점진적인 설계를 하는 방식으로 문제를 해결해 나가자.