패턴을 활용한 리팩터링

패턴을 활용한 리팩터링 - 조슈아 케리에브스키 지음, 윤성준.조상민 옮김/인사이트

저자는 왜 이 책을 쓴 것인가?

책 도입부를 참고해서 쓰면 다음과 같다.

1995년도에 출간된 [ Design Patterns : Elements of Reusable Object-Oriendted Software, Addison-Wesley, 1995] 가 센세이션을 일으킨 이후로 참으로 많고 많은 책들이 디자인 패턴을 위해서 쓰여져왔다.(오로지 패턴만을 위해서..)

그리고 마틴파울러의 Refactoring이라는 책이 나오면서 저수준(개인적 수준)에서 프로그램을 개발할 때 읽기 편하고 유지보수하기 좋은 코드를 유지하는 기법이 또하나의 관심사로 대두된다.

Refactoring 에서는 메소드나 필드를 뽑아서 부모 클래스로 옮기거나 또는 자식 클래스로 옮기고 추상 메소드를 두는 방법, 인터페이스를 뽑아내는 방법 등, 일일이 다 외우기도 벅차보이는 다양한 기법들을 소개하고 있다.

저자의 말에 따르면 한동안 이 두 개념이 마치 별개의 것으로 간주되어온 경향이 있었다는 것인데 이 책에서는 이 두개의 방법이 서로 무관하지 않음을 말하고 있다. 프로젝트가 진행되고 코드가 누적되면 코드 곳곳에 때가 끼게 되는 법. 이 때를 벗겨내는게 바로 리팩토링인데, 중요한 것은 이 리팩토링의 지향점이 바로 다양한 패턴이라는 점.

기존에 패턴이 적용되는 방식을 함 살펴보자.

업무 분석이 끝나고 상위 수준에서 설계가 도출된 후 하위 설계에서

"그래, 이 부분에서는 이 패턴이 쓰이는게 좋겠군"

위와 같은 식으로 사전 설계 단계에서 패턴이 도입되고 인터페이스, 추상클래스, 구체 클래스가 툭툭 튀어나온다. 이런 설계가 계속되면 될수록 시스템을 이루는 코드에 중복과 너저분한 코드같은 부채(라고 책에서는 언급함)가 쌓이게 된다. 미진한 설계와 패턴의 과잉이 빚은 부채가 생기기 마련이고 이를 제거 하기위해서 "패턴을 고려한 리팩토링"이 필요함을 말한다.

기존의 코드를 손봐서 필드를 옮기고 메소드를 손보고 인터페이스를 추출하고 delegation을 정의하는 다양한 리팩토링을 통해서 전체 코드가 간결해지고 특정 패턴에 이르게 만든다는 것이다.(물론 특정 패턴에 이른 코드는 이해하기 쉽고 간결한 특징을 가져야 한다. 그렇지 않다면 리팩토링은 할 필요가 없거나 제대로 하지 못한 것).

책의 주제는 p37에 명확하게 나온듯하다.

이 책이 패턴과 리팩터링 사이의 공백을 연결하기는 하지만, 이 둘 간의 연결은 위대한 저술인 [Design Patterns]의 결론 부분에 언급되어 있다.

우리의 디자인 패턴은 리팩터링의 결과로 나온 구조를 반영한다.
따라서 디자인 패턴은 리팩터링의 목표점이 되는 것이다.[DP, 354]

Martin Fowler 또한 [Refactoring] 의 앞부분에서 비슷한 의견을 말했다.

패턴과 리팩터링 사이에는 자연스런 관계가 있다. 패턴은 도달하고 싶은 곳이고, 리팩터링은 그곳으로 가는 방법이다. [F, 107]

이 책을 통해서 자신이 패턴 만능주의에 빠진 것은 아닌지 스스로를 검증해보는 마음가짐을 갖는다면 좋겠지만 역시 이론을 실제에 적용하는 것은 쉬운 일은 아닌듯.. 내가 나를 뒤돌아 본다는건 결코 만만한 일이 아니다. ( 그럴 시간도 없을 때가 많고 -_-;;)

"무조건 패턴을 도입하는건 바람직하지 않을 수 있다" 라는 점을 염두에 두고 코드를 개량해서 읽기 쉽고 보수하기 쉬운 최선의 상태를 유지하려고 노력하는게 중요하지 않을까 싶다.