2. 리팩터링 원칙 | 리팩터링

2.1 리팩터링 정의

수많은 다른 소프트웨어 개발 용어와 마찬가지로, 리팩터링도 다소 두리뭉실한 의미로 통용된다. 이 책에서는 다음과 같이 정의한다.

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

코드를 정리하는 작업을 모두 리팩터링이라고 표현하고 있는데, 정의에 따르면 특정한 방식에 따라 코드를 정리하는 것만이 리팩터링이다.

코드베이스를 정리하거나 구조를 바꾸는 모든 작업을 재구성이라고 하고, 리팩터링은 재구성의 특수한 한 형태라고 보면 될 것 같다.

겉보기 동작이라고 한 것은 리팩터링 하기 전과 후에 똑같이 동작해야하는데, 내부에 함수 콜 스택이라든지 성능적인 부분들은 달라질 수 있다고 하는 것이다.

성능 최적화를 위해서는 코드가 더 복잡해 질 수도 있다.

2.2 두개의 모자

저자는 기능 추가와 리팩터링을 동시에 하지 않는다고 한다. 그리고 두 작업에서의 작업 방식의 차이가 분명하게 있다고 한다.

2.3 리팩터링하는 이유

리팩터링이 만병통치약은 아니지만, 코드를 건강한 상태로 유지하는데 도와주는 약임은 틀림 없다고 한다. 치약 같은 존재인가 보다.

다음과 같은 이유로 리팩터링을 한다고 한다.

• 리팩터링하면 소프트웨어 설계가 좋아진다.
• 리팩터링하면 소프트웨어를 이해하기 쉬워진다.
  • 다른 사람이 아닌 내가!
• 리팩터링하면 버그를 쉽게 찾을 수 있다.
• 리팩털이하면 프로그래밍 속도를 높일 수 있다.

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

저자는 한 시간 간격으로 한다고 한다. 돈 로버츠는 같은 일을 세번 반복하면 리팩터링을 하라고 한다. 저자는 다음과 같을 때 리팩터링 하는 것을 추천한다고 한다.

• 준비를 위한 리팩터링: 기능을 쉽게 추가하게 만들기
  • 기능 추가하기 직전에 리팩터링을 한다고 한다.
• 이해를 위한 리팩터링: 코드를 이해하기 쉽게 만들기
  • 리팩터링 하다보면 이해가 잘되더라.
• 쓰레기 줍기 리팩터링
  • 쓸데없는 코드를 줄일 수 있다.
• 계획된 리팩터링과 수시로 하는 리팩터링
  • 사실 리팩터링은 프로그래밍 과정에서 자연스럽게 해야하는 것이다.
  • 보기 싫은 코드를 발견하면 리팩터링하자. 그런데 잘 작성된 코드 역시 수많은 리팩터링을 거쳐야한다.
  • 무언가를 수정하려 할 때는 먼저 수정하기 쉽게 정돈하고, 그런 다음 쉽게 수정하자.
• 오래걸리는 리팩터링
  • 리팩터링은 대부분 몇 분 안에 끝난다. 하지만 어떨 때는 대규모 리팩터링을 해야할 때가 있다.
    • 라이브러리 교체 작업, 컴포넌트를 빼내는 잡업 등이 있다.
• 코드 리뷰에 리팩터링 활용하기
  • 여러 의견을 모을 수 있어서 좋다고 한다.
  • 옆에 앉혀놓고 같이 하는 방식이 좋다고 한다.
• 관리자에게는 뭐라고 말해야 할까?
  • 리팩토링을 불신하는 관리자도 있다. 일을 진전시키지 않고 망치기만 한 경우가 있기 때문이다.
• 리팩터링하지 말아야 할 때

2.5 리팩터링 시 고려할 문제

• 새 기능 개발 속도 저하

  • 리팩터링의 궁극적인 목적은 개발 속도를 높여서 더 적은 노력으로 더 많은 가치를 창출하는 것이다.
  • 보통 리팩터링 하면 더 빨리 기능 개발 할 수 있다. 리팩터링이 더 좋다. 리팩터링이 최고다. 리팩터링은 하면 개발이 빨라진다.

• 코드 소유권

  • 남의 코드여서 소유권이 없는 경우는 리팩터링에 방해가 된다.
  • 코드 소유권을 느슨하게 하는 것이 좋다.

• 브랜치

  • 일반적으로 브랜치를 하나씩 맡아서 작업하고 합친다.
  • 브랜치 통합 주기를 3일 단위로 짧게 관리해야 한다고 주장하는 사람이 많다. 이런 방식을 지속적 통합(CI), 트렁크 기반 개발(TBD)라고 한다.
    • 저자는 하루에 한번은 해야한다고 한다.
    • CI와 리팩터링을 합쳐서 익스트림 프로그래밍이라고 한다고 한다.

• 테스팅

  • 리팩터링 과정에서 오류를 빨리 잡기 위해서 자가 테스트 코드를 만들어야한다.

• 레거시 코드

  • 보통 테스트를 염두에 두고 설계한 시스템이 아니면, 테스트 코드를 사용하기가 까다롭다.
  • 리팩토링을 통해서 하나씩 나눠서 테스트를 하는 방식으로 테스트 코드를 작성한다.

• 데이터베이스

  • 데이터 베이스 열 이름 바꿀 때 관련된 함수를 모두 바꿔야한다.
    • 이 때 과정을 잘게 나눠서 바꿔준다.

이후 내용에는 그냥 리팩터링과 관련된 여러 얘기들을 하는데... 그냥 긍정적인 얘기 나열이어서 목차만 적고 생략하도록 하겠다. 리팩터링은 확실히 필요한 것 같다.