1장 리팩터링 리팩터링하기

리팩터링 구성요소

1. 스킬
   • 어떤 코드가 잘못됐으며 리팩터링이 필요한지 파악하는 스킬
   • 코드 스멜 -> 익히기 어려움
2. 문화
3. 도구
   • 작업이 안전하다는 것을 보장할 무언가
   • 예: 자동 테스트

앞으로의 목적: 테스트 및 추상적인 코드 스멜 없이 리팩터링 하기

리팩터링을 왜 해야할까?

p.2
리팩터링은 '기능을 변경하지 않고 코드를 변경하는 것'을 의미한다.

왜 리팩터링을 해야 할까? 좋은 코드를 만들기 위해서다.

그럼 좋은 코드는 무엇일까? 책에서는 '사람이 읽기 쉽고, 유지보수가 용이하며, 의도한 대로 잘 동작하는 코드'라고 말한다. 즉, 리펙토링은 기존 코드를 '사람이 읽기 쉽고, 유지보수가 용이하며, 의도한 대로 잘 동작하는 코드'로 바꾸는 작업을 뜻한다.

그럼 왜 이런 작업을 해야 할까? 그건 효율적으로 일하기 위해서라고 생각한다. 책에서는 리팩터링의 첫 번째 이유를 '경제적'인 것으로 꼽는다.

1. 사람이 읽기 쉬우면, 가독성이 높아져서 작성된 코드를 읽고 이해하는데 들이는 시간이 줄어들고 새로운 기능을 구현하기 위한 시간을 확보할 수 있다.
2. 유지보수가 용이하면, 버그가  줄어들고 수정이 쉬워진다.
3. 그리고 이런 코드는 생각하기 편하다. 머리 속에서 코드를 해석하는 일이 줄어들거나 쉬워지면 그만큼 편할 것이다.

무엇을, 언제, 어떻게 리팩터링할 것인가?

보통 '냄새나는' 코드를 리팩터링 해야 한다고 하지만 실제로 코드를 보면 바로 눈에 보이지 않는다. 자세한 내용은 클린 코드 책을 보면 좋을 것 같고, 이 책에서는 '규칙'을 제시한다. 이 편이 더 명확하긴 한듯! 애초에 책 제목부터 규칙이긴 하다.

그럼 언제 리팩터링을 해야할까? 늘, 정기적으로, 가능하면 일상 업무에 통합하는 것이 좋다. 

1. 새로 코드를 작성하는 경우 > 코드를 전달하기 전에 규칙을 위반했는지 확인한다.
2. 레거시 코드인 경우 > 새 코드를 쉽게 추가할 수 있게 리팩터링을 먼저한다.
3. 하면 안되는 경우 >
   1. 한 번 실행하고 삭제할 코드
   2. 폐기 전 유지보수 모드에 있는 코드
   3. 엄격한 성능 요구사항이 있는 코드

안전한 리팩터링 방법

1. 자동화된 테스트
   • 가장 좋지만 효과적인 테스트 방법을 배우는 것은 어렵다.
2. 잘 구조화된 리팩터링 패턴
3. 버전 관리
4. 컴파일러