들어가며

옛날 옛적에 한 컨설턴트가 개발 프로젝트를 점검하러 파견을 나갔다. 작성된 코드를 보니 클래스 상속 구조가 시스템의 주축을 이루고 있었고, 전반적으로 아주 엉망이었다.

컨설턴트는 프로젝트 팀장에게 코드를 살펴보면서 정리하라고 권했지만 팀장은 콧방귀를 뀌는 듯한 태도였다. 어쨌든 그 코드는 문제없이 돌아가는 데다 중요한 일정들이 코앞이었으니 그럴 만도 했다. 팀장은 나중에 여유가 생기면 하겠다고 했다.

6개월 후 그 프로젝트는 완전히 망했다. 코드가 너무 복잡해서 디버깅도 할 수 없었고 최소한의 성능 요건을 맞추는 것도 불가능했다.

켄트 벡이 그 프로젝트를 새로 시작하기 위한 컨설팅을 맡았다. 시스템의 거의 모든 부분을 처음부터 새로 작성해야 했다. 켄트는 일하는 방식에 여러모로 변화를 줬는데, 그중 가장 핵심은 리팩터링을 활용해 코드를 꾸준히 정리하게 했다는 점이다. 결국 두 번쨰 시도는 성공했고, 전적으로 리팩터링 덕이었다.

리팩터링이란

리팩터링은 겉으로 드러나는 코드의 기능(겉보기 동작)은 바꾸지 않으면서 내부 구조를 개선하는 방식으로 소프트웨어 시스템을 수정하는 과정이다. 버그가 생길 가능성을 최소로 줄이면서 코드를 정리하는 정제된 방법이다. 요컨대, 리팩터링한다는 것은 코드를 작성하고 난 뒤에 설계를 개선하는 일이다.

리팩터링의 각 단계는 간단하다 못해 지나칠 정도로 단순하다. 한 클래스의 필드를 다른 클래스로 옮기고, 일부 코드를 메서드 밖으로 빼서 별도의 메서드로 만들고, 코드 일부를 상속 구조의 위/아래로 올리거나 내리는 등의 작업이다. 이런 사소한 수정도 누적되면 설계가 놀랍도록 개선된다. 소프트웨어가 부식된다는 개념의 정반대가 바로 리팩터링이다.

리팩터링을 하면 일의 균형이 바뀐다. 처음부터 완벽한 설계를 갖추기보다는 개발을 진행하면서 지속적으로 설계한다. 시스템을 구축하는 과정에서 더 나은 설계가 무엇인지 배우게 된다. 그 결과, 개발의 시작부터 끝날 때까지 프로그램은 줄곧 우수한 설계를 유지한다.

누가 읽어야 하나

이 책은 소프트웨어 개발을 직업으로 하는 전문 프로그래머를 위해 쓰였다.

리팩터링은 코드에 집중하지만, 사실 시스템 설계에 미치는 영향이 상당히 크다. 그래서 선임 개발자나 아키텍트라면 반드시 리팩터링의 원리를 이해하고 프로젝트에 활용해야 한다.

책 전부를 읽지 않고도 내용 대부분을 습득하려면 다음과 같이 하자.

• 리팩터링이 뭔지 모른다면 1장을 읽자. 1장의 예시를 보면 리팩터링 진행 절차를 명확하게 알 수 있다.
• 리팩터링해야 하는 이유를 모르겠다면 1장과 2장을 읽자. 리팩터링이 무엇이고 왜 필요한지 설명해준다.
• 리팩터링해야 할 곳을 찾고 싶을 때는 3장을 읽자. 리팩터링이 필요할 만한 곳에서 보내는 신호(악취)를 잡아내는 요령을 설명해준다.
• 리팩터링을 실습하고 싶다면 1장부터 4장까지는 꼼꼼히 읽고, 나머지를 빠르게 훑어보자. 카탈로그 부분은 어떤 기법들이 있는지 정도만 대략 보면 되지, 세세한 부분까지 전부 이해할 필요는 없다. 리팩터링을 당장 실시해야 할 때 해당 기법 부분을 펼쳐 자세히 읽고 따르면 된다. 카탈로그는 그때그때 찾아보는 부분이므로 한 번에 이어서 읽는 것은 불필요하고 비효율적이다.