리팩터링 저자는 거의 1시간 간격으로 리팩터링을 한다고 한다. 그러다보니 저자의 작업 흐름에 리팩터링을 녹이는 방법이 여러가지 였고 이번에는 그 흐름들을 설명한다. 3의 법칙 1. 처음에는 그냥 한다. 2. 비슷한 일을 2번째로 하게 되면 (중복이 생겼다는 사실에 당황스럽겠지만), 일단 계속 진행한다. 3. 비슷한 일을 3번째로 하게 되면 리팩터링 한다. 준비를 위한 리팩터링: 기능을 쉽게 추가하게 만들기 리팩터링하기 가장 좋은 시점은 코드베이스 기능을 새로 추가하기 직전이다. 이 시점에 현재 코드를 살펴보면서, 구조를 살짝 바꾸면 다른 작업을 하기가 훨씬 쉬워질만한 부분을 찾는다. 가령 내 요구사항을 거의 만족하지만 리터럴 값 몇개가 방해되는 함수가 있을 수 있다. 함수를 복제해서 해당 값만 수정해도 ..

리팩터링은 소프트웨어의 모든 문제점을 해결하는 만병통치약을 아니지만, 코드를 건강한 상태로 유지하는 데 도와주는 약임은 분명하다. 1. 리팩터링하면 소프트웨어 설게가 좋아진다. : 리팩터링하지 않으면 소프트웨어의 내부 설계(아키텍쳐)가 썩기 쉽다. 아키텍처를 충분히 이해하지 못한 채 단기 목표만을 위해서 코드를 수정하다 보면, 기반 구조가 무너지게 된다. 코드 구조가 무너지기 시작하면, 악효과가 누적된다. 코드만으로 설계를 파악하기 어려워질수록 설계를 유지하기 어려워지고, 설계가 부패되는 속도는 더욱 빨라진다. 같은 일을 하더라도 설계가 나쁘면 코드가 길어지기 십상이다. 사실상 같은 일을 하는 코드가 여러 곳에 나타날 수 있기 때문이다. 그래서 중복코드 제거는 설계 개선 작업의 중요한 한 축을 차지한다...