디자인 패턴에 익숙한 나에게 "패턴 = 디자인 패턴 " 이라는 선입견이 많이 그려저 있었나 보다.
부분이 전체인양 판단하고 있었다는게 바로 이런 문제에 오류였는데
이런 예는 "라면 = 신라면" 의 공식과도 같을 수 있는것 같다.
책을 읽기 전에 안티패턴의 내용을 담은 이책은 디자인 패턴을 실날하게 비판하고
디자인 패턴과 반대 진영에서 뭔가를 이야기 할것 만 같았다.
실제로 이름에서 풍기는 이미지가 그러하지 않는가? 안/티/ ...
하지만 책보고 나서 용어적 해설만 가지고 섵부른 판단을 금해야 겠다는 생각이 들었다.
과연 안티패턴에 대한 쉬운 이해가 무엇일까?
"디자인 패턴은 그들을 정상까지는 데려다 줄 수 있었지만 그들을 안전하게 아래로
돌아오게 할 수 는 없었다. 위험한 시기에 산 정상세엇 머무르지 않고 돌아온 다거나, 시간을 정확히
지켜야 한다는 등의 등반 관련 안티패턴을 적절히 응용했더라면 이런 참혹한 결과는 일어나지 않았을
것이다. (책 47 Page)"
디자인 패턴이 에베레스트를 손쉽게 오르게 하는 방법이라면
안티 패턴은 오르다 발생할 수 있는 문제점들에 대한 대응책과 대응 방법을 이야기 한것이라고 할 수 있다.
물론 알고 있는 분들도 있겠지만 책은 위와같은 대전제 아래에서 소스코드 하나 보여주고
리팩토링의 과정을 거쳐가며 하나 하나 풀어나가는 과정을 알려주고 있는 전개 방식을 가지고 있다.
개인적으로 안티패턴을 쉽게 보다 관심있게 본 목록이 하나 있다.
Round-tripping이 해당하는 항목인데 EJB로 개발했다가 속도가 느리고
서비스가 심하게 부하가 걸린 사례를 경험해서 그런지 Round-tripping에 부분에서는 저자의 친절한 설명이 고맙게 다가왔다.
책을 보는 방법
> 부록A 먼저 보기 : 부록을 먼저는게 이 책을 빠르게 이해하는 방법이다.
용어적 설명을 간단하게 해 놨기 때문에 부록을 먼저 보고
10Chapter 를 보면 핵심을 크게 벗어 나지 않는 범위에서
책의 액기스만을 맛 볼 수 있을것이라 생각되어 진다.
모든 책이 그렇지만 책장 한장 한장이 감동스럽게 다가오지는 않는것 같다.
그중에 IT서적의 경우 필요한것만 꺼내보는 성향이 좀 강한것 같다 (나^^)
하지만 이미 알고있더라도, 다른곳에서 알았더라도
한권즈음은 독파를 해보는것은 어떨까 생각해본다.
