리팩토링-서문

옛날에 한 컨설턴트가 개발 프로젝트에 파견되었다. 그 컨설턴트는 작성된 코드의 일부를 보았는데, 시스템의 중심에는 클래스 구조가 있었다. 그 구조를 여기저기 훑어보는데, 무척 난잡했다. 상위 레벨의 클래스가 작동에 대한 어떤 가정을 하고 있었고, 상속된 코드에도 가정이 포함되어 있었다. 그러나 그 코드는 모든 서브클래스에 맞는 것은 아니었기 때문에 오버라이드가 많이 쓰였다. 만약 수퍼클래스가 조금 수정된다면, 오버라이드가 훨씬 적게 필요할 것이다. 다른 곳에서는 수퍼클래스의 의도를 적절하게 이해하지 못했고, 수퍼클래스에 이미 있는 기능이 중복되었다. 또 다른 곳에서는 여러 개의 서브클래스가 동일한 작업을 하고 있었는데, 이것은 명확하게 수퍼클래스로 옮겨질 수 있는 것들이었다.

컨설턴트는 프로젝트 매니저에게 코드를 보고 정리할 것을 권고했지만, 프로젝트 매니저는 시큰둥했다. 코드는 그럭저럭 작동하는 것 같았고, 스케줄은 빡빡했다. 매니저는 나중에 하겠다고 말했다.

컨설턴트는 또한 그 클래스 구조에서 작업하고 있는 프로그래머들에게 무슨 일이 일어나고 있는지를 보여주었다. 그 프로그래머들은 똑똑했고, 문제점을 알게 되었다. 그들은 그것이 자신들의 잘못이 아니라는 것을 알고 있었다. 문제를 지적하기 위해서는 때때로 새로운 눈이 필요하다. 그래서 그 프로그래머들은 그 클래스 구조를 정리하는데 하루 이틀 정도를 보냈다. 작업을 마쳤을 때, 그들은 기능을 줄이지 않으면서도 코드의 반을 삭제했다. 그들은 결과에 기뻐했고, 새로운 클래스를 추가하거나 또는 다른 시스템에서 클래스를 사용하기가 빨리지고 쉬워졌다는 것을 알았다.

프로젝트 매니저는 별로 기뻐하지 않았다. 스케줄은 빡빡하고 할 일도 많은데 이들 프로그래머가 이틀 동안이나 작업을 하고도 몇 달 후에는 납품해야 하는 시스템에 새로운 기능을 추가한 것이 없기 때문이었다. 예전의 코드도 잘 동작했고 디자인도 그럭저럭 괜찮았다. 프로젝트는 학자들을 즐겁게 하는 코드가 아닌, 작동하는 코드를 납품하는 것이다. 컨설턴트는 코드정리가 시스템의 다른 부분에 대해서도 작업되어야 한다고 제안했다. 이것은 아마 프로젝트의 진행을 한두 주 멈추게 할 것이다. 모든 활동은 코드가 더 좋게 보이도록 하는 것이지, 새로운 기능을 추가하는 것은 아니다.

이 이야기를 읽고 느낌이 어떤가? 코드 정리를 더하자는 컨설턴트의 제안이 적절하다고 생각하는가? 아니면 "작동하면 고치지 말라."는 상투적인 공학 격언을 따를 것인가?

여기서 나에게 약간의 편견이 있었다는 것을 인정해야 겠다. 그 컨설턴트는 나였다. 6개월 후 그 프로젝트는 실패했는데, 상당 부분은 코드가 너무 복잡해서 디버그나 적절한 퍼포먼스튜닝을 할 수 없었기 때문이었다.

Kent Beck이 컨설턴트로 투입되어 프로젝트를 다시 시작했는데, 거의 모든 시스템이 처음부터 다시 작성되었다. 그는 몇가지를 다르게 했는데, 가장 중요한 것은 리팩토링을 이용하여 지속적으로 코드를 정리하도록 주장한 것이었다. 결과는 성공이었고, 리팩토링이 이 성공에 중요한 역할을 했다. ...

결론

리팩토링을 이용하여 지속적으로 코드를 정리 하면 프로젝트는 성공할 수 있다.

리팩토링을 왜 해야하는지에 대해서 잘 설명해주고 있다.

출처 : 리팩토링 by 마틴 파울러