리팩터링 2판 2장에서는 리팩터링 원칙에 대해서 다룬다. 리팩터링 소프트웨어의 겉보기 동작은 유지한 채, 코드를 이해하고 수정하기 쉽게 내부 구조를 변경하는 기법 2장에서는 리팩터링을 왜, 언제 해야하는지에 대해 길게 설명한다. 항상 내가, 레거시 코드를 보면서 "지금은 할일이 있으니까 나중에 고쳐야지" 했던 것들이 사실은 잘못된거라는 걸 깨달았다. 가장 공감가고 핵심적인 내용을 세가지만 추려본다. 당장 피쳐 개발하느라 바쁜데 리팩터링 할 시간이 없어요 이에 대해 마틴파울러는 리팩터링은 항상 해야하는 것이라고 설명한다. 따로 리팩터링을 하기 위한 시간을 두는게 아니다. 예컨데 기존 코드에 깔끔하게 기능을 추가하려면 기존 구조를 변경해야되는 경우가 있다. 이런 경우 새로운 기능을 추가하기전, 시간을 할애해..

챕터 1 내용중 감명깊은(?) 부분 테스트케이스는 필수다. 리팩토링 시 발생하는 문제를 조기에 발견할 수 있다. 임시변수를 최소화한다. 이를 위해 함수의 결과값을 변수에 넣지않고 바로 함수를 호출한다. 이걸 두고 함수 인라이닝 이라고 부른다. 로직이 복잡한 경우 함수 추출 이라는 기법을 통해 로직에서 기능을 추출한다. 변수와 함수의 이름은 항상 명확하게 짓는다. 변수와 함수명이 짓기 힘들다면, 그 함수의 역할이 너무 많은건 아닌지 의심해볼 필요가 있다. 컴퓨터가 이해하는 코드는 바보도 작성할 수 있다. 사람이 이해하도록 작성하는 프로그래머가 진정한 실력자다. 좋은 코드를 가능하는 확실한 방법은 '얼마나 수정하기 쉬운가' 다.