free-vahn

본문

Refactoring과 Pattern의 관계는 모순적이면서 의미심장합니다.
전통적인 방법론적 접근법은 강화된 디자인에서 S/W를 구현하는 반면 XP 적인 접근법은 구현 먼저, 좋은 디자인 도출의 방법입니다.
GoF가 설명했던 Design for change와 Target for Refactoring의 관계와도 맥을 같이하는데요..  
즉, 모든 발생할 수 있는 상황에 대비하도록 패턴들을 적용해서 절대 뚤리지 않는 방패(디자인)을 만들 것인가? 시행착오를 통해 정제되는 모델을 패턴으로 인도할 것인가? 의 접근법의 차이 입니다.
상철님이 아래 게시판에서 말했던 대로 이런 서로간의 다른 목적과 접근법이 상반된 둘 간의 허를 보완하고 있습니다.

일반적인 패턴의 사용 시점은 분석모델 설계, Architecture 수립단계, 디자인 단계, 구현 단계에 걸쳐 각각 Analysis, Architectural, Design, Idiom 패턴을 적용합니다.
하지만 '얼마만큼 적용할 것인가?'가 관건이 될 겁니다.
패턴을 배웠던 초창기에 오버하게 패턴을 적용해서 예쁜 디자인을 만들고 구현시에 감당치 못한 군더더기 때문에 자승자박했던 경험이 많았습니다.
이런 전차로, 제 사견으로는 예측가능하고 이 중에서 특히 진짜로 발생할 사실들에만 패턴을 적용하는 게 좋을 듯 합니다.
그리고 발견되는 예측 못 했던 문제들을 Simple한 코드로 구축하고 (XP의 접근법 처럼) 어느정도 완성도가 이뤄졌을 때 패턴을 적용하는 것이죠..
하지만 여기에도 역시 개발자의 능력에 따라 '정도'의 차이가 있을 겁니다.
경험 많은 개발자들은 패턴을 적용할 범위가 넓겠고 그렇지 않은 개발자들은 적을 겁니다.
즉, 아무리 Pattern Vocabulary나 Pattern System, Pattern Laguage를 많이 확보하고 있다 하더라도 선견지명이 있거나 신기 있는 개발자가 아니면 보배로 만들기 힘들다는 거죠..
- 소프트웨어의 위계적 고찰에서도 말했던 바와 같이 바로 이 부분이 소프트웨어적 접근법에 회의를 느끼는 부분이지만요..

물론 초창기 패턴의 교육시에 패턴의 장점을 침소봉대했던 것이 사실입니다.
'패턴이면 다 돼!!' 라는 투의 매력을 강조한 반면 적용 시 주의점에 대해서는 설명하지 않았던 탓이겠죠..
"고기를 잡았으면 그물을 버려라"란 왕필의 말 처럼 패턴을 배웠으면 최대한 패턴을 적용하지 않도록 하라고 권하고 싶습니다.

제게 패턴을 소개해줬던 재하님의 "패턴이 지은 죄는 패턴으로 닦아라!!" 란 말이 기억납니다.
이제 RF란 든든한 도구가 생겼으므로 "패턴이 못 본 구멍은 RF로 막아라!!"라고 수정하고 싶은데요.. 패턴과 RF와의 관계가 바로 이런 조화가 될 것 같습니다.
이런 전제라면 패턴을 사용할 단계는 RF를 기준으로 개발전과 후라는 symmetrical한 구도가 되는군요...

하지만 여기에 시행착오와 선경지명이라는 인적인 요소가 자리하는군요..
바로 이 구멍을 설명할 수 있고 밝혀진다면 아마도 이 논의는 종결 될 것 같습니다.


끝으로 위의 Pattern과 Refactoring에 투영된 접근법 (RUP vs. Xp)전쟁은 이제 변증적인 방법을 모색할 단계가 아닌가 생각이 듭니다.


objectworld.org