많은 분이 기다리셨던 The Productive Programmer가 현재 1차 교정 작업을 마쳤습니다.
(어쩔수 없이 블로깅하게 되네요.. 참 민망합니다. 아무래도 저의 사적인 일이 아니니, 이해해 주시길 부탁드립니다. 🙂 )
지식 공유와 큰 열정을 가지시고 번역관련 개론 서적까지 읽으시면서 고생해 주신 김현수 님 덕분에 드디어 이 서적이 한국에 나오네요.
좋은 서적이 국내에 나오게 되어 너무 기쁩니다.
김 현수님이 베타리더를 모으고 직접 베타리더 분들과 대화를 나누는게 맞지만, 현재 호주로 이민을 가셔서 부득이하게 제가 베타리더를 모으고, 가교의 역할을 하고자 합니다.
사실 번역 거리를 제가 현수님에게 드려서, 책임감을 가지고 할수밖에 없네요.
에전 More Joel on Software에서 많은 분이 참여해 주신것 처럼, 이번에도 활발한 신청 부탁드립니다.
이번 제 1회 닷넷 커뮤니티 컨퍼런스에 발표한 TP 자료를 많은 분이 요청하셔서 부득이하게 공유합니다.
- 패턴의 정의
- 패턴에 대한 오해와 진실
- 패턴으로 가는 길
- 패턴 빌드 오더
- 패턴 + 생산성 두마리의 토끼 잡기
블로그 포스트를 적으면서.. 보람된 것은 그나마 저의 부족한 지식을 좋게 봐 주시는 분이 많고, 격려해 주시는 분이 많다는 것입니다.
전화 위복이라고 했던가요 🙂
이번 사건으로 오히려 다시 한번 아키텍팅에서 SoC가 차지하는 중요성에 대해서 생각할 수 있게 되었습니다. 개인적으로는 유명 컨설턴트들과 함께한 프로젝트 만큼 더 큰 교훈이었다고 생각합니다. 저의 아키텍팅 공부방향의 진로를 정하게 되었다고 할까요..
제가 이글을 쓴 이유는 저의 아이디와 패턴의 남용에 대해서 같이 언급하셔서, 큰 상처를 받았습니다. 제가 패턴쪽으로 많은 활동을 하고 있었는데요.
직접 대화를 나누어 오해를 풀었습니다.
저를 향한 글인줄 알았습니다. 직접 대화를 통해 그것이 아니었음을 알았습니다. 제가 너무 민감하게 대했던것 같습니다.
toby님에게 모욕을 당했다는 말은 정중히 사과하겠습니다.
다행히 toby님과 대화는 매우 산뜻하게 끝나고, 심지어 여러가지 mission을 주셨습니다. 🙂
이번 논쟁은 결국 몇분이 말씀해주신것 처럼, 각자가 느낀 도메인의 경험의 차이 그리고 생각의 차이라고 이해해 주셨으면 합니다.
디키 님의 말처럼 반론을 다는것 보다는 다시 저의 의견을 말씀 드리는 것이 올바른 글쓰기라고 생각하여 다시 글을 씁니다.
Ripple Effect (파문효과)에 대한 생각들..
SoC 에대한 애기를 그만두길 원했으나, 영회님이 또 글을 포스팅 하셔서 저의 생각을 적습니다. 일단 잠이 오지 않습니다. 🙂 누워도 누워서 잘려고 해도 계속 마음이 아파옵니다.
일단 SoC 애대한 애기는 어느 정도 마무리 해야 될듯 합니다. 더 글을 적는다고 해도. 참 이게 소모적인 논쟁만 될까하고 생각이 듭니다.
영회님이 적은포스트 입니다. SoC – Separation is not components.
이 글을 보면 저의 의견과 약간 대치 됩니다. Concern이라는 것은 Component가 될수도 있고 아닐수도 있습니다.
Component라는 단어에 대한 정의를 무얼로 보느냐에 중요하겠죠. 솔직히 말해서 Separation의 단위를 배포의 문제가 중요시 되는 경우 얼마든지 Component 단위로 볼수가 있다는 것이 저의 생각입니다.
.NET Framework Design Guidelines에 언급한 것처럼, Component를 하나의 진화되는 유닛 (a evolving unit)으로 정한 경우죠.
그리고 Separation에 영향을 미치는 Concern들은 결국 그 프로젝트에서 가장 적합한 요소들이 상호 균형을 맞추어 정해진다고 봅니다.
그게 생각의 범위든, 부하의 분리든, 배포의 문제든 기타 등등.
저 같은 경우는 배포가 중요시 되기 때문입니다. Robert C. Martin의 Principles of Package Architecture가 제가 하고 있는 프로젝트와는 밀접한 관련이 있기 때문입니다.
많은 사람들은 자신이 가진 것을 놓지 않을려고 합니다.
계속해서 갖기 위해서 싸우고, 서로를 짖밟는 세상이 된거 같습니다.
전 너무나 욕심이 많았던것 같습니다.
데브피아의 시삽, Microsoft MVP, EvaCast의 리더, 저의 수많은 글들 ….
이제 좀 비울때가 온거 같습니다.
가지고 있는것을 비우지 않으면, 성장할 수 없음을 잘 알기에…
당분간 번역과 집필활동에 전념하겠습니다. 마음이 정리되면 돌아오겠습니다…
SoC와 복잡성에 대한 고찰..
전 왜 이런 소리(Toby님, 안영회님) 를 들어야 할지 모르겠네요. 일단 전 문제 그 자체에 집중해서 포스팅 하겠습니다. 🙂
복잡성(Complexity) 에 대한 생각들..
먼저 Complex (복잡하다)에 대한 명확한 정의를 내리고자 합니다.
어원적으로 보면 Com(Together) + Ple (Tie , Bind) 의 의미로 구성되어 있습니다. 여러개가 묶여 있는 것을 복잡하다고 말을 합니다. 그것이 서로 얽히고 섥혀 있으면 복잡하다는 것이지요. 결국 복잡의 의미는 Toby님과의 말에 별 의견이 없습니다.
우리가 느끼는 복잡성(Complexity)를 숨길 수는 있어도 결코 사라지지는 않는 다는 것입니다. 누군가는 떠 안아야 된다는 거지요..
우리가 심플함의 대명사로 말하는 Apple 제품이 기존 타사 제품의 복잡함과 비교 설명할 때 자주 보여지는 그림이 한 장 있습니다.
Architecture 101 