오늘  Rebecca의 강의를 들은 후, 아는 분과 설계와 구현간의 gap에 대한 이야기를 들었습니다.

아무리 좋은 설계라도, 개발자가 전혀 다르게 구현한다면. 어떻게 해야 할까요? 그리고 RTC와 같은 좋은 툴들이 보급된다고 해서 과연 이러한 문제가 해결될까요?  이러한 툴에 맞게 개발 문화가 정착된 회사가 한국에 몇이나 있을까요?  형식적인 것이 아닌, 진정한 개발 문화가..

솔직히 이런 문제는 한국에서개발자 대비 QE의 비율이 너무 빈약해서, 스펙에 맞게 잘 구축된 테스트 환경도 찾아보기 힘들고, 실제 현장과 동일한 환경 또한 만들기 쉽지가 않습니다. 이러한 것이 선행되어 강력히 제약을 가해야, 비로서 올바른 구조가 될듯 한데. 참으로 어려운 이야기인것 같습니다. 거기다 Requirement 변경이 빗발치는 SI에서는말이죠.  Owner의 말한마디로.. 되는 경우도 종종 있지만요.

이러한 하소연은 하루 이틀 나온 애기도 아니고, 정말 이땅의 많은 Manager와 Architect가 싸워서 합리적인 문화와 구조를 만들어야 가능하지 않을까요? 이런 현실과 부딪혀 이기기가 쉽지 않다고 생각이 들기도 합니다. 그래도 다 같이 머리를 맞대고 도전해 봐야죠.

계속 읽기

bobPLoP에서 수많은 거장들을 만났습니다. 거장들중 우리나라에 그리 많이 알려지지 않은 분들을 하나씩 소개할려고 합니다.   왜냐면 이들의 연구분야들을 하나씩 소개하는 것이 어떤 분들에게는 귀중한 정보다 될것이고, 많은 도움이 될거라고 생각이 듭니다.

Robert Hanmer씨는 이번에 저희 Half-Push/Half-Polling 패턴의 목자 (Shepherd) 이셨습니다. (PLoP에서는 패턴을 제출하면 완성도 있는 패턴을 한번 거른다음, 각 패턴다마 패턴을 잘 쓸수 있게 목자(멘토)를 지정해 줍니다. 그럼 목자와 함께 계속 애기를 나누면서, 패턴들을 수정해 나가는 거죠. 그 이후 저자 워크샾을 통해 한번 더 다듬게 되고, 최종 논문이 완성됩니다.)

PLoP의 BootCamp를 수년간 Linda Rising과 이끌고 있었고, 상당히 부드럽고 배려심이 많으신 분입니다. 이하 Bob 아저씨(Robert를 다 Bob이라고 부릅니다)는 현재 Alcatel-Lucent (Lecent Technolgies and AT&T)라는 Telecomunication 회사에서 Consulting Member로  근무중이며,  고 수준의 가용성(availiability)를 보장하는 시스템을 꾸준히 만들어 오셨습니다.

이러한 패턴들은 고수준의 품질을 요구하는 제조업과 아주 밀접한 연관이 있으므로, 국내 제조업에 종사하는 소프트웨어 개발자에게는 상당히 도움이 될만한 서적이라고 생각됩니다.  그리고 인사이트에서 판권을 확보하고 현재 번역중이라고 하니 조만간 번역서를 만나 보실 수 있으리라 생각이 듭니다.

계속 읽기

이번 PLoP 에서 프린터로 받은 Pattern Template을 번역해서 올립니다.

기존 Pattern Template에 달리 추가된 내용이 Resulting Context/Side Effects 입니다. 지금까지 패턴들은 장점만 너무 기술한 경향이 있는데. 이제 이 패턴을 적용할 경우 발생하는 Side-Effect도 기술하길 권하고 있습니다.

영어 원문을 그대로 번역한 것이라. 약간 매끄럽지도 않을 수도 있습니다. 🙂

계속 읽기

굳이 이 분이 누군지 말 안해도 다들  아실겁니다. 🙂 바로 Grady Booch 입니다.  UML을 탄생시킨 3인방 중에 한명이며, 지금의 소프트웨어 공학에 지대한 영향을 끼치신 분이죠 .

Grady Booch의 끊임없는 지적 호기심을 보여주는 좋은 사이트가 있어서 소개합니다.

바로  Handbook of Software Architecture 라는 사이트 입니다. 아마 아실 분은 다 아시겠죠 :).   여기에 Pattern들에 대한 보물이 숨겨져 있습니다.

바로 지구상에 발표된 패턴들을 잘 요약해 놓고, 적절하게 다양한 관점으로 분류하고 잘 요약정리해 놓았습니다. 단순히 GoF, POSA, PLoP 에 나온 분류 보다 훨씬 자세하게 잘 분류되어 있고, 지구상에 많은 패턴을 끊임없이 요약 정리하고 계시다니..  대단하시네요. 저도 나름대로 분류 작업을 진행해야 겠네요 🙂

계속 읽기

드디어 PLoP에 제출한 논문이 Published Paper List에 올라왔습니다. 이거 감회가 무척 새롭네요.   제 블로그를 통해서 제가 직접 만든 패턴을 소개하다니…  여튼 신선하고 기분 좋은 일입니다 🙂

패턴의 이름은  Half-Push / Half-Polling 입니다.  (눈치있는 분은 아시겠지만 작명은 “Half-Sync/Half-Async”에서 얻어왔습니다. 🙂 )

패턴의 주 아이디어는 Upgrade시 일반적으로 사용되는 두가지 기법(Push 방식 과 Polling 방식)을 혼합하여 장점은 살리고 단점은 제거한 패턴입니다.

계속 읽기

제 2회 아키텍트 Summit에 발표 자료입니다.  아키텍트에 ‘아’짜도  따라가지 못하는 저가, 우여 곡절 속에 수많은 쟁쟁한 분과 함게 발표를 맡게 되었습니다.

다른 쟁쟁한 아키텍트 분들에게 누가 되지 않았길 바라며, 발표를 준비했습니다.  주제는 패턴과 EA의 활용에 대해서 간략히 언급해 드렸습니다.

계속 읽기

pattern_meeting

안녕하세요 🙂  일전에 약속한 대로 여러가지 패턴 이야기들을  가져 왔습니다!!

사실 이미 많은 분이 접하셨을 겁니다.  바로 마소 5월호에 저희 스터디 팀이 Cover Story를 기고했는데요 그 내용들입니다.

처음 기고를 하신 분들도 있고, 아닌 분도 있지만  모두에게  좋은 경험이 되었다고 생각이 듭니다. 저 역시 저희 커뮤니티 맴버들이 뭉쳐서 이런 좋은 글을 만들었다는 것이 매우 큰 기쁨으로 느껴집니다.

사실 커뮤니티를 운영하면서 가장 만족감을 느끼는 것은, 서로에게 성장할 수 있는 경험과 기회를  주고 나누는 것이죠. 그리고 같이 성장해 가는 것을 보고 느낄때 기쁨은 이루 말할수 없습니다.

이 것이 제가 생각하는 커뮤니티의 올바른 모습이며, 앞으로도  잘 유지될 수 있도록 노력하겠습니다.  🙂   그럼 이번에 저희 EVA 팀이 기고한 글들을 차례대로 간략히 소개하겠습니다.

계속 읽기

“패턴을 좀더 쉽게 학습하고 실제 프로젝트에 잘 적용할 방법이 없을까요?”  필자가 강의를 마치고 종종 듣는 질문이다. 부족하지만 필자가 공부한 패턴 지식들과 경험들을 합쳐, 독자 여러분에게 패턴을 학습, 활용하기 위한 시행착오를 조금이나마 줄일 수 있는 지름길을 안내하고자 한다.

손 영수 arload@live.com | 데브피아 Architecture 시삽과 Microsoft MVP로 활동 중이며, 데브피아 소프트웨어 공학 스터디인 Eva팀의 리더이다. 부족한 실력이지만 지식을 나눌 때는 누구보다 ‘부자’라는 자부심을 가지고 지식 나눔에 힘쓰고 있다. Pattern 전도사를 꿈꾸고 있으며, PLoP와 같은 Pattern 학회를 국내에 만들기 위해 힘 쏟고 있다.

요즘은 대학교 학부생의 교과 과정으로 들어갈 정도로 패턴은 많은 이들에게 알려져있다.. 하지만 필자 주위에는 패턴을 잘 활용하여, 성공적으로 프로젝트를 마무리 했다거나 좋은 결과를 보았다는 말보다는, 오히려 많은 불신들과 하소연을 들었다. 왜 이런 상황이 발생했을까? 이 글을 통해 독자들이 패턴에 오해를 풀고, 올바른 시선을 가지길 바라며 글을 적는다.

패턴을 대하기 이전에 마음가짐 – 유연성, 확장성

많은 분들과 패턴을 주제로 애기하다 보면, 패턴에 대한 잘못된 관점을 가진 분들을 종종 만난다. 패턴을 통해, 비약적인 성능 향상, 생산성이 증대 될거라 생각하는 분도 있고 심지어 Silver Bullet (은총알)로 생각하는 분도 있다. 물론 제한적인 도메인 안에서 성능, 생산성 향상을 가져 올 수 있는 패턴도 있지만, 패턴 자체의 목적은 유연성과 확장성에 초점을 맞추고 있다.

초창기 객체 지향(80년대)의 가장 중요시 여기는 패러다임은 “Reuse (재사용)” 이였다. 그래서 Component와 같은 이상적인 패러다임이 나오기도 했다. 마치 Lego와 같이 조립만 하면 만들어지는 Legoware를 꿈꾸어 오면서…

하지만 현재 소프트웨어는 어떠한가? 빈번하게 바뀌는 고객의 요구사항, 몇 명 이서 만들 수가 없을 정도로 거대해진 규모, 길어진 소프트웨어 생명주기를 가진 녀석들이 대부분이다. 그렇기 때문에 소프트웨어가 가져야 할 중요한 설계 방향이 재 사용성 보다는 쉽게 변화를 수용할 수 있는 유연성(Flexibility)과 확장성(Extensibility)이 대두되게 되었다. 만약 여러분이 유연성과 확장성에 초점을 맞춘 설계에 관심이 있다면, 패턴은 좋은 도구가 된다. 하지만, 최적화나 성능 개선이 목적이시라면 패턴보다는 알고리즘을 공부하는 것이 더 낫다.

그리고 패턴을 쉽사리 적용하지 못하는 여러 가지 장벽들이 곳곳에 존재한다. 패턴에 대한 불신들이다. 지면상의 제약으로 이 모든 내용을 언급하기가 한계가 있으니 예전에 필자가 마소 2007년 8월호에 기고한 “미워도 다시 보는 패턴 이야기”를 꼭 읽어보길 권한다. 패턴의 정의, 원칙, 참고할만한 설계구조도 설명하고 있다.

계속 읽기

이번 제 1회 닷넷 커뮤니티 컨퍼런스에 발표한 TP 자료를 많은 분이 요청하셔서 부득이하게 공유합니다.

  • 패턴의 정의
  • 패턴에 대한 오해와 진실
  • 패턴으로 가는 길
  • 패턴 빌드 오더
  • 패턴 + 생산성 두마리의 토끼 잡기

계속 읽기

Pattern이라는 분야에서 GoF의 Design Patterns가 가지는 의미는 굳이 말을 하지 않아도 될듯 합니다.

몇몇 지식 계층들을 위한 학회에서나 애기되어지고 있는 Pattern들을 일반인들에게 알리는 신호탄 같은 존재이기 때문입니다.

예전 블로그에 올린 글이지만, 패턴을 공부하시거나 접하시는 분에게는 꼭 필요한 내용이라  재 포스팅 합니다.

이 포스트를 통해서 Design Pattern의 두번째 원칙에 대한 오해들을 여러분과 공유하고자 합니다.

문제가 되는 두번째 원칙을 보도록 하죠.  🙂

Favor Object Composition over Class Inheritance

이 말의 의미는 원문 그대로 해석을 한다면 클래스 상속보다는 객체 조합을 선호해라 라는 애기입니다.  대부분의 시중에 나와 있는 책들이 상속보다는 조합을 선호하는 것으로 의미를 파악하고 전달하고 있습니다.

물론 그 당시 CBD가 널리 유행했던 것도 한 몫했죠 🙂   과연 이말이 맞는걸까요?

6년 동안 다양한 패턴에책들을 본 경험을 들어 볼때, 상속이라는 것은 모든 패턴에 사용되고 있었습니다.

거기다 graybox 즉 whitebox(상속)과 blackbox(조합)을 함께 적용하는 것이 패턴계의 철학으로 굳혀져 있어서 과연 이말이 맞는지 많은 의구심을 가지게 되었습니다.

계속 읽기