많은 분이 기다리셨던 The Productive Programmer가 현재 1차 교정 작업을 마쳤습니다.
(어쩔수 없이 블로깅하게 되네요.. 참 민망합니다. 아무래도 저의 사적인 일이 아니니, 이해해 주시길 부탁드립니다. 🙂 )
지식 공유와 큰 열정을 가지시고 번역관련 개론 서적까지 읽으시면서 고생해 주신 김현수 님 덕분에 드디어 이 서적이 한국에 나오네요.
좋은 서적이 국내에 나오게 되어 너무 기쁩니다.
김 현수님이 베타리더를 모으고 직접 베타리더 분들과 대화를 나누는게 맞지만, 현재 호주로 이민을 가셔서 부득이하게 제가 베타리더를 모으고, 가교의 역할을 하고자 합니다.
사실 번역 거리를 제가 현수님에게 드려서, 책임감을 가지고 할수밖에 없네요.
에전 More Joel on Software에서 많은 분이 참여해 주신것 처럼, 이번에도 활발한 신청 부탁드립니다.
이번 제 1회 닷넷 커뮤니티 컨퍼런스에 발표한 TP 자료를 많은 분이 요청하셔서 부득이하게 공유합니다.
- 패턴의 정의
- 패턴에 대한 오해와 진실
- 패턴으로 가는 길
- 패턴 빌드 오더
- 패턴 + 생산성 두마리의 토끼 잡기
제가 이글을 쓴 이유는 저의 아이디와 패턴의 남용에 대해서 같이 언급하셔서, 큰 상처를 받았습니다. 제가 패턴쪽으로 많은 활동을 하고 있었는데요.
직접 대화를 나누어 오해를 풀었습니다.
저를 향한 글인줄 알았습니다. 직접 대화를 통해 그것이 아니었음을 알았습니다. 제가 너무 민감하게 대했던것 같습니다.
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가 제가 하고 있는 프로젝트와는 밀접한 관련이 있기 때문입니다.
SoC와 복잡성에 대한 고찰..
전 왜 이런 소리(Toby님, 안영회님) 를 들어야 할지 모르겠네요. 일단 전 문제 그 자체에 집중해서 포스팅 하겠습니다. 🙂
복잡성(Complexity) 에 대한 생각들..
먼저 Complex (복잡하다)에 대한 명확한 정의를 내리고자 합니다.
어원적으로 보면 Com(Together) + Ple (Tie , Bind) 의 의미로 구성되어 있습니다. 여러개가 묶여 있는 것을 복잡하다고 말을 합니다. 그것이 서로 얽히고 섥혀 있으면 복잡하다는 것이지요. 결국 복잡의 의미는 Toby님과의 말에 별 의견이 없습니다.
우리가 느끼는 복잡성(Complexity)를 숨길 수는 있어도 결코 사라지지는 않는 다는 것입니다. 누군가는 떠 안아야 된다는 거지요..
우리가 심플함의 대명사로 말하는 Apple 제품이 기존 타사 제품의 복잡함과 비교 설명할 때 자주 보여지는 그림이 한 장 있습니다.
예전에 Framework’s Day에 발표했던 Framework Engineering 의 동영상 강좌를 지난 토요일날 찍었습니다.
Framework 구축시 여러분이 겪을 시행 착오를 조금이나마 줄일 수 있길 바라며 강좌를 공유합니다.
이 강좌에 대한 내용은 저의 머리에서 나온 것이 아니라, .NET Framework의 설계자인 Krzysztof Cwalina의 강좌와 현재 저희가 번역하고 있는 Framework Design Guideline 2nd 추가해 정리한 것입니다.
이 발표의 전체적인 내용은 아래와 같습니다.
Seperation of Concerns (걱정거리들의 분리) 줄여서, SoC 라는 용어를 들어 보셨나요? 걱정 거리또는 관심거리의 분할(분리)라고 부르는 데요 🙂
각 모듈마다 특정 문제에만 집중해서, 해결할 수 있게 나누어서 생각하자는 것입니다. N – Tier 기반의 Application이 좋은 예라고 할 수 있을 겁니다. (물론 성능적인 이슈도 있지만요)
하지만 이 철학으로 인해 너무나 잘게 클래스들이 쪼개져서, 실제 프로젝트를 할때 기능 하나를 추가하기 위해 여러개의 객체를 수정해야 하는 엄청난 고통을 가져오는 상황이 발생합니다 발생하기도 합니다.
안녕하세요. 요즘 블로깅이 뜸하다고 몇분이 저에게 사적으로 말씀하시더라구요 🙂
이유는 나중에 말씀 드리도록 하고, 조만간 있을 세미나 2개에 대한 정보를 알려 드리고자 합니다.
1. 미워도 다시보는 패턴 이야기 (4월말에 있을 초대형 세미나에 한 섹션)
행사의 구체적인 정보를 말해 드릴수 없지만, 조만간 1000명이상을 위한 세미나가 4월말에 열릴 예정입니다.
추후 행사에 대한 자세한 내용을 Update하도록 하고, 제가 진행하는 세션 정보를 공유하고자 합니다.
패턴 이라는 것이 너무 GoF 패턴, 그리고 소프트웨어 설계 기술에만 치우쳐 한국 개발자에게 공유되어 지고 있는것 같습니다.
패턴에 대한 오해들과 프로세스나 실제 개발자 삶에 도움이 되는 패턴 이야기를 여러분들에게 전달하고자 합니다.
그리고 Code 보다 Model에서 생각하는 방법과 개발 생산성을 증대시키는 이야기들도 나눌 겁니다. 아마 이게 백미라고 생각이 드네요.
이미 대전에 한 중소기업에서 세미나를 진행했고, 피드백이 매우 괜찮았습니다. 4월 말 기대하셔도 좋습니다.
2월 기고에 이은 Framework Engineering Part II를 여러분에게 공개합니다.
Part I에 대한 글에 대한 평이 없어서? 과연 좋은 글을 썼는가 다시 의문을 가집니다. 😦
.NET 진영은 Java 진영보다직접 Framework를 구축하는 일 보다는, 사용하는 일이 더 많으니 그러겠지 하고 혼자 생각하고 있습니다. 🙂
여기서 소개한 툴들과 거의 일대일 대칭이 되는 툴들이 Java 진영에도 있으니 Technic 적인 측면보다, Framework를 구축할때 어떠한 것들을 고려해야 되는지 경험과 프로세스 측면에서 저희들의 부족한 글을 이해해 주시길 부탁드립니다.
많이 부족한 지식이지만 조금이나마 다른 분들에게 도움이 되는 글이였으면 좋겠네요 🙂
이번 글은 지난호에 이어 아래의 주제들중 아키텍쳐에 다 못다한 애기부터 다루었습니다.
Pattern이라는 분야에서 GoF의 Design Patterns가 가지는 의미는 굳이 말을 하지 않아도 될듯 합니다.
몇몇 지식 계층들을 위한 학회에서나 애기되어지고 있는 Pattern들을 일반인들에게 알리는 신호탄 같은 존재이기 때문입니다.
예전 블로그에 올린 글이지만, 패턴을 공부하시거나 접하시는 분에게는 꼭 필요한 내용이라 재 포스팅 합니다.
이 포스트를 통해서 Design Pattern의 두번째 원칙에 대한 오해들을 여러분과 공유하고자 합니다.
문제가 되는 두번째 원칙을 보도록 하죠. 🙂
Favor Object Composition over Class Inheritance
이 말의 의미는 원문 그대로 해석을 한다면 클래스 상속보다는 객체 조합을 선호해라 라는 애기입니다. 대부분의 시중에 나와 있는 책들이 상속보다는 조합을 선호하는 것으로 의미를 파악하고 전달하고 있습니다.
물론 그 당시 CBD가 널리 유행했던 것도 한 몫했죠 🙂 과연 이말이 맞는걸까요?
6년 동안 다양한 패턴에책들을 본 경험을 들어 볼때, 상속이라는 것은 모든 패턴에 사용되고 있었습니다.
거기다 graybox 즉 whitebox(상속)과 blackbox(조합)을 함께 적용하는 것이 패턴계의 철학으로 굳혀져 있어서 과연 이말이 맞는지 많은 의구심을 가지게 되었습니다.
Architecture 101 