디자인 패턴에 대한 글을 쓰다가, 문득 생각이 나서 같이 쓴다.
'디자인 패턴'하면 흔히 같이 언급되는 것으로, '디자인 패턴의 남용'이란 것이 있다. 이것은, 쉽게 말하면, 약간의 유사성이 있는 문제가 발생했을 때, 그 유사성 만으로 해당 패턴을 도입하는 행위를 말한다. 이 행위가 너무도 빈번히1 발생하는 이유는, 아마도 '방금 배운 것을 (어떻게든, 억지로라도) 써먹기 위함'일 것이다.
그런데, 사실 이러한 문제는 '디자인 패턴의 남용'에서만 발생하는 문제는 아니다. 많은 개발자들은, 새로운 기술을 익히면, 어떻게든 그 기술을 현재 프로젝트에 도입하고야 만다. 그 기술이 무엇이든지, 또한 현재 프로젝트가 추구하는 가치와는 전혀 상관이 없더라도.
이러한 과정은, 어린 아이가 말을 하기 위해 옹알이를 시작하는 것처럼, 배움의 일부분일 수 있다.
하지만, 그러한 옹알이가 실제 프로젝트에 적용이 되어서는 결코 안된다.2
실제 프로젝트에 익숙치 않은 기술을 억지로 도입하는 것은, 마치 9시 뉴스에서 메인 앵커가 갑자기 옹알이로 방송을 하는 것과 마찬가지다.
말 그대로 방송 사고다.
'Software Engineering' 카테고리의 다른 글
| 오래 전 있었던 일 1 (1) | 2010/08/01 |
|---|---|
| 디자인 패턴과 셰익스피어 (0) | 2010/03/13 |
| 옹알이와 방송 사고 (2) | 2010/03/13 |
| 정석은 익히는 즉시 잊어라 (1) | 2010/03/13 |
| 비용 절감과 가치 증대 (0) | 2010/02/01 |
| [추천서적] Implementation Patterns - Kent Beck (6) | 2009/11/19 |
댓글을 달아 주세요
이게 가장 큰 문제는 기획이나 pm이 새로운 기술을 알아왔을때가 심각하죠
이런게 있던데 여기에 적용좀 해보지 그래?
이건 좀.. 안어울리는데요..
일단 해보고 한번 보자..
닝기.. -ㅅ-;
priority가 높고 risk가 낮은 작업부터 선행하는 건 프로젝트 관리의 기본인데, 가끔 그런 기본조차 갖추지 못한 관리자들을 만날 때가 있지요.
저는 그런 이유에서, 저를 신뢰하지 않는 고객과는 계약하지 않고, 또 고객과 저 사이에 다른 사람이 끼도록 놔두지도 않습니다.
살아남으려면 그것 밖에는 방법이 없는 것 같아요.