소프트웨어를 보다 쉽게 이해할수 있고, 적은비용으로 수정할 수 있도록 겉으로 보이는 동작의 변화업이 내부의 구조를 바꾸는 것.
리팩토링을 할때는 기능을 추가해서는 안되고, 단지 코드의 구조에만 신경써야 한다. 그리고 어떠한 테스트도 추가하지 않는다.
대부분의 비즈니스 애플래케이션은 데이터메이스 스키마와 밀접하게 결합되어 있으므로 데이터베이스 변경을 어렵게하고, 또한 데이터 마이그레이션도 그 요소중하나이다.
객체지향 데이터베이스가 아닌경우 객체모델과 데이터베이스 모델사이에 별도의 소프트웨어 계증을 두어 해결한다.
일부 객체지향 데이터베이스는 한 객체에서 다른 객체로 자동 마이그레이션을 지원하나, 마이그레이션을 하는 동안의 시간을 보상해주지는 않는다.
h4.인터페이스변경
공표된 인터페이스를 변경하는 경우, 예전의 인터페이스와 새로운 인터페이스를 모두 유지해야 하므로 예전의 인터페이스가 새로운 인터페이스를 호출하도록 하면 된다.
h4.리펙토링이 어려운 디자인 변경
현재의 디자인을 대신할 수 있는 대안을 고려하면서 리팩토링을 상상한다.
리팩토링이 쉬워보이면 가장 간단한 디자인을 고르고, 그렇지 않으면 디자인에 더 많은 노력을 기울임
h4.언제 리펙토링을 하지 말아야 하는가?
리팩토링은 사전디자인의 대안이라고 말할수는 없으나, 사전디자인에 강조했던 궁극적인 솔루션을 찾으려 할 필요없이 적절한 솔루션을 찾는다.
융통성있는 솔루션은 처음 생각했던 방향을 바꾸는 것에는 더 유연하지만, 모든곳에 융통성을 제공하는 것은 전체 시스템을 훨씬 더 복잡하고 유지보수하기 어렵게 한다.
이로 인해 융통성의 희생없이 단순한 디자인으로 유도할 수 있다.
리팩토링은 소프트웨어를 더 느리게 할 것이지만 반면에, 소프트웨어에 대한 퍼포먼스 튜닝을 더 쉽게 할 수 있는 바탕을 만들어 놓는다.
1980년대 초부터 스몰토크를 사용하고 있던 Ward Cunningham과 Kent Beck에 의해 리팩토링의 중요성을 인식