SoC와 복잡성에 대한 고찰..
전 왜 이런 소리(Toby님, 안영회님) 를 들어야 할지 모르겠네요. 일단 전 문제 그 자체에 집중해서 포스팅 하겠습니다. 🙂
복잡성(Complexity) 에 대한 생각들..
먼저 Complex (복잡하다)에 대한 명확한 정의를 내리고자 합니다.
어원적으로 보면 Com(Together) + Ple (Tie , Bind) 의 의미로 구성되어 있습니다. 여러개가 묶여 있는 것을 복잡하다고 말을 합니다. 그것이 서로 얽히고 섥혀 있으면 복잡하다는 것이지요. 결국 복잡의 의미는 Toby님과의 말에 별 의견이 없습니다.
우리가 느끼는 복잡성(Complexity)를 숨길 수는 있어도 결코 사라지지는 않는 다는 것입니다. 누군가는 떠 안아야 된다는 거지요..
우리가 심플함의 대명사로 말하는 Apple 제품이 기존 타사 제품의 복잡함과 비교 설명할 때 자주 보여지는 그림이 한 장 있습니다.
Seperation of Concerns (걱정거리들의 분리) 줄여서, SoC 라는 용어를 들어 보셨나요? 걱정 거리또는 관심거리의 분할(분리)라고 부르는 데요 🙂
각 모듈마다 특정 문제에만 집중해서, 해결할 수 있게 나누어서 생각하자는 것입니다. N – Tier 기반의 Application이 좋은 예라고 할 수 있을 겁니다. (물론 성능적인 이슈도 있지만요)
하지만 이 철학으로 인해 너무나 잘게 클래스들이 쪼개져서, 실제 프로젝트를 할때 기능 하나를 추가하기 위해 여러개의 객체를 수정해야 하는 엄청난 고통을 가져오는 상황이 발생합니다 발생하기도 합니다.
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월호에 다루었습니다.
IT에 몸담은 이상 발전하는 기술들을 무시할수 없습니다.
수 많은 대형밴더들은 끊임없는 기술을 만들고 발전 시킴으로써 새로운 가치를 창출해야 살아 남을수 있으며, 저희 역시 끊임없이 그러한 기술들을 습득하고 배워나가야 됩니다.
하지만 엄청난 서포라이트를 바라보면서 사라진 기술들을 볼때, 어떻게 기술들을 객관적으로 바라 보아야 할까요?
그걸 설명해 주는 좋은 그래프가 있어 소개하고자 합니다.
2009년도이 왔습니다. 저의 블로그를 애독하시는 모든 분들 새해 복 많이 받으세요 🙂
새해 부터 어떠한 글을 Posting 해야 하나 많은 생각 끝에 기러기에 이은 또 다른 새 이야기를 전혀 드리고자 합니다.
이 세상에서 한번도 쉬지않고 가장 오랫동안 나는 새가 무엇일까요?
독수리? 기러기?
정답은 믿기 어렵겠지만.. 단지 600g의 조그만 몸무게를 가진 이 도요새입니다.
도대체 얼마나 이 새가 멀리 날길래 이럴까 ? 하고 생각했지만 이 조그만 새가 날아가는 거리를 한번 보도록 하시죠.
아키텍팅을 바라보는 입장에서.. 또 실제 코드를 구현하는 개발자의 입장에서.. 개발자와 아키텍트가 서로 꿈꾸는 생각의 차이라고 할까요? 세상엔 개발자가 꿈꾸는 이상적인 아키텍트도, 아키텍트가 꿈꾸는 이상적인 개발자도 없습니다. 이것이 현실이죠 🙂 적절히 맞추어 갈수 밖에..
제가 2008년 10월호 마소에 팀 생산성 향상을 위한 패턴 이야기를 기고 했는데요.
이번에는 팀이 아닌 개개인이 생산성을 향상 시킬수 있는 좋은 지침이 되는 서적이 나와 소개하고자 합니다.
The Productive Programmer (O’ Relly)
Abstract
이 책의 저자 Neal Ford는 리펙토링의 저자인 Martin Fowler가 있는 ThoughtWorks의 이사로 많은 컨퍼런스에 DSL 전도사로 활동중입니다.
이 책은 생산성 향상을 위해 조직적인 측면보다는 개발자의 개인적은 측면에 대해서 초첨을 맞추고 있습니다.
개발자로서 자주 사용하는 운영체제, 프로그램들의 숨겨진 단축키와 초기 셋팅 방법와 같은 Mechanic Skill 뿐만 아니라, 향상된 코드를 생성하기 위한 툴들, 코딩 스킬, 개발자가 지켜야 하는 규범들을 공유하고 있습니다.
일전에 Dependency에 대한 고찰이라는 글로, Dependency의 종류와 xDepend 툴들을 소개한 적이 있습니다.
이번 POST는 윗 글의 연장선상으로 Dependency 를 해결하기 위한 올바른 설계 방법 몇가지를 소개하고자 합니다.
물론 재미난(?) 그래프로 여러분의 시스템의 Depedency를 파악하는 것을 보여드리고 싶지만.. 모든 일에는 순서가 있는 법. 여러분이 와 닿는 그림과 코드로 간단히 설명드리도록 하겠습니다.
Dependency가 없는 상태로 시스템을 구축한다는 것은 불가능합니다. 재사용의 미덕이 바로 Dependency의 또다른 이름이기도 하죠.
어떻게 하면 Dependency를 잘 관리할수 있을까? 그 해답을 제시해주신 아키텍트를 소개하고자 합니다.
그 분은 바로 Object Mentor의 Robert C. Martin 입니다. Clean Code의 저자로써 알려져 있지만, 사실 이것보다 이름을 더 크게 알리게 한 주역은 패턴의 5가지 법칙(OCP, DIP, LIP, ISP, SRP)입니다.
그런데 이 5원칙의 빛에 가려 숨겨진 Principle이 하나 있는데요. 이름하여 패키지 구조의 원칙들 (Principles of Package Architecture) 입니다.
이 논문에서 Dependency를 깨거나 완화하는 방법들을 여러분에게 소개하고자 합니다.
Architecture 101 
