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(조합)을 함께 적용하는 것이 패턴계의 철학으로 굳혀져 있어서 과연 이말이 맞는지 많은 의구심을 가지게 되었습니다.
마소 1월호 주제인 Application과 Framework 동시 개발하기에 이어, 2월호에는 Framework 설계시 실제 필요한 Engineering 기법들에 대해 기고했습니다. 물론 결코 저의 머리에서 나온 것은 아닙니다. 🙂
이 글은 .NET Framework를 설계한 Krzysztof Cwalina의 TechED 강의 내용과 저의 지식을 덧분인 글입니다.
Krzysztof Cwalina의 강좌를 보시고 싶으신 분은 여기를 클릭하시길 바랍니다.
12월호 있었던 세미나와 지금까지 블로그에 기고한 Post들을 모은 내용이기 때문에, 저의 블로그 독자 분들(?)에게는 미안하네요 🙂
이번 글은 크게 6가지 주제들을 다룹니다.
● 조직 (가장 강력한 설계 툴)
● 계획 (프레임워크를 올바르게 구축하 기 위한 계획)
● 아키텍처 (오랫동안 사용할 수 있는 품질 좋은 프레임워크를 만들기 위한 고려사항들)
● 설계 (품질을 보장하기 위해 고려할 사항들)
● 개발 (프레임워크를 만들기 위해 팀플레이 시 고려해야 되는 사항들)
● 그 외에 고려해야 되는 것들 (가독성, 문서화)
이중 조직, 계획, 아키텍쳐에 대한 내용을 2월호에 다루었습니다.
패턴계에는 크게 두가지 박스가 있습니다.
GoF 패턴 책을 읽으신 분이라면 하얀 박스(상속)와 검은 박스(조합) 애기는 많이 들어 보셨을 겁니다. 혹시 회색 박스는 들어보셨나요? 🙂
12월에 진행했던 Framework’s Day 세미나의 내용들을 연달아 마소에 기고하고자 합니다.
거리상의 제약으로 참가하지시 못했던 분이나, 관심 있었던 분들에게 도움이 되었으면 합니다. 🙂
Framework’s Day에서 Framework에 대한 기본 개론과 Ralph Johnson의 Evolving Framework에 대한 이야기는 이미 2008년 11, 12월호에 김용현님이 작성을 해주셨구요.
그 뒤를 이어 Framework Design Guidelines 2nd Edition 번역 팀들이 실제 Framework를 구축히 만날수 있는 문제들에 대한 글을 기고하고자 합니다.
그리고 권효중님이 iBatis.NET과 Spring.NET에 대한 애기들을 진행 함으로써, 총 7회의 Framework 강좌가 마치게 됩니다.
세미나시 진행했던 ASP.NET MVC Framework와 ADO.NET Entitiy Framework은 이미 예전에 장현희님과 한용희님이 마소의 연재로 기고하셔서, 이번 Framework 강좌에서는 포함되어 있지 않습니다. 🙂
이번 기고 내용인 Application과 Framework 동시 개발하기 에 대한 주제는, 예전에 포스팅한 “성공적인 Framework 구축” 에 대한 연장 선상에 있는 글입니다.
Architecture 101 
