[리팩토링 2판] Chapter 2. 리팩터링 원칙 정리

1. 리팩터링 정의

리팩터링 : 소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법

리팩터링(하다) : 여러 가지 리팩터링 기법을 적용해서 소프트웨어를 재구성하다.

• 특정한 방식에 따라 코드를 정리하는 것만이 리팩터링이다.
• 리팩터링하는 동안에는 코드가 항상 정상 작동하기 때문에 전체 작업이 끝나지 않았더라도 언제든 멈출 수 있다.

누군가 "리팩터링하다가 코드가 깨져서 며칠이나 고생했다"라고 한다면, 십중팔구 리팩터링한 것이 아니다.

• 리팩터링 과정에서 발견된 버그는 리팩터링 후에도 그대로 남아있어야 한다.
• 리팩터링은 성능 최적화와 비슷하다.
  코드를 이해하고 수정하기 쉽게 만드는 것. 반면, 성능 최적화는 오로지 속도 개선에만 신경 씀.

2. 리팩터링의 목적

• 기능을 추가할 때는 '기능 추가'만! 기존 코드는 절대 건드리지 않고 새 기능을 추가하기만 한다.
• 리팩토링을 할 때는 기능 추가는 절대 하지 않고 오로지 코드 재구성에만 전념!

3. 리팩터링하는 이유

소프트웨어 설계가 좋아진다.

• 리팩터링하지 않으면 소프트웨어의 내부 설계(아키텍처)가 썩기 쉬움.
• 단기 목표만을 위해 코드를 수정하다 보면 기반 구조가 무너지기 쉬움.
  코드만 봐서는 설계를 파악하기 어려워짐.
  코드 구조가 무너지기 시작하면 악효과가 누적됨.
• 같은 일을 하더라도 설계가 나쁘면 코드가 길어지기 십상. 👉 중복 코드 제거의 중요성
• 중복 코드를 제거하면 모든 코드가 언제나 고유한 일을 수행함을 보장할 수 있으며, 이는 바람직한 설계의 핵심.

소프트웨어를 이해하기 쉬워진다.

• 컴퓨터에게 시키려는 일과 이를 표현한 코드의 차이를 최대한 줄여야한다.
• 프로그래밍은 결국 내가 원하는 바를 정확히 표현하는 일이다. 사람이 가장 중요.
• 코드의 목적이 더 잘 드러나게, 내 의도를 명확하게 전달하도록 개선할 수 있다.
• 기억할 필요가 있는 것들은 최대한 코드에 담으려고 하자.

버그를 쉽게 찾을 수 있다.

• 코드를 이해하기 쉽다 = 버그를 찾기 쉽다
• 리팩터링하면 코드가 하는 일을 깊이 파악하게 되면서 새로 깨달은 것을 곧바로 코드에 반영하게 됨.
• 켄트 벡의 말 "난 뛰어난 프로그래머가 아니에요. 단지 뛰어난 습관을 지닌 괜찮은 프로그래머일 뿐이에요."

프로그래밍 속도를 높일 수 있다.

• 소프트웨어 내부 품질의 차이
  내부 설계가 잘 된 소프트웨어는 새로운 기능을 추가할 지점과 어떻게 고칠지를 쉽게 찾을 수 있다.
• 모듈화가 잘되어 있으면 전체 코드 베이스 중 작은 일부만 이해하면 됨.
• 코드가 명확하면 버그를 만들 가능성도 줄고 버그를 만들더라도 디버깅하기가 훨씬 쉽다.
• 내부 품질이 뛰어난 코드베이스는 새 기능 구축을 돕는 견고한 토대가 된다.
• 설령 프로그램 요구사항이 바뀌더라도 설계를 지속해서 개선할 수 있다.

4. 언제 리팩터링해야 할까?

비슷한 일을 세 번째 하게 되면 리팩터링한다.

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

• 현재 코드를 살펴보면서 구조를 살짝 바꾸면 다른 작업을 하기가 훨씬 쉬워질 만한 부분을 찾는다.
• 버그를 잡을 때도 마찬가지.
  오류를 일으키는 코드가 세 곳에 복제되어 퍼져 있다면, 우 선 한 곳으로 합치는 편이 작업하기에 편함.

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

• 코드를 수정하려면 먼저 그 코드가 하는 일을 파악해야 함.
• 리팩터링하면 머리로 이해한 것을 코드에 옮겨 담을 수 있음.

쓰레기 줍기 리팩터링

• 간단히 수정할 수 있는 것은 즉시 고치고, 시간이 좀 걸리는 일은 짧은 메모만 남긴 다음, 하던 일을 끝내고 나서 처리하기.
• 캠핑 규칙이 제안하듯, 항상 처음 봤을 때보다 깔끔하게 정리하고 떠나자.
• 각각의 작은 단계가 코드를 깨뜨리지 않음! 👉 작업을 잘게 나누면 몇 달에 걸쳐 진행하더라도 그 사이 한 순간도 코드가 깨지지 않기도 함.

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

• 리팩터링 일정을 따로 잡아두지 않고, 기능을 추가하거나 버그를 잡는 동안 리팩터링도 함께 한다.
  👉 프로그래밍 과정에 자연스럽게 녹인 것

  보기 싫은 코드를 발견하면 리팩터링하자. 그런데 잘 작성된 코드 역시 수많은 리팩터링을 거쳐야 한다.
  (요구 사항이 달라지거나 우리의 이해도가 높아짐에 따라 더 나은 코드를 개선하기 위해)

무언가 수정하려 할 때는 먼저 수정하기 쉽게 정돈하고(단, 만만치 않을 수 있다) 그런다음 쉽게 수정하자. - 켄트 벡

• 새 기능을 추가하기 쉽도록 코드를 '수정'하는 것이 그 기능을 가장 빠르게 추가하는 길일 수 있음.
• 참고 사항) 버전 관리 시스템에서 리팩터링 커밋과 기능 추가 커밋을 분리해야 한다는 말도 있음. (각자의 팀에 적합한 방식으로 적용하는 것이 최선임)

오래 걸리는 리팩터링

• 리팩토링은 주어진 문제를 몇 주에 걸쳐 조금씩 해결해가는 편이 효과적일 때가 많다. 👉 다른 일과 리팩토링을 함께 병행한다.

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

• 코드 리뷰는 개발팀 전체에 지식을 전파하는 데 좋다.
• 리팩터링은 다른 이의 코드를 리뷰하는 데도 도움이 된다.
• 리팩터링은 코드 리뷰의 결과를 더 구체적으로 도출하는 데에도 도움이 된다.

리팩터링하지 말아야 할 때

• 지저분한 코드를 발견해도 굳이 수정할 필요가 없다면 리팩터링하지 않는다.
• 리팩터링하는 것보다 처음부터 새로 작성하는 게 쉬울 때도 리팩터링하지 않는다.