지난 주말 (2012년 5월 20일) 코엑스에서 스마트 개발자 협회가 주관하는 글로벌 커뮤니티 써밋에  EVA 커뮤니티 연사로 발표를 했습니다.

먼저 이번 발표에 많은 도움을 준 소프트웨어 마에스트로 멘티인 오유환, 강미경, 김나래, 손윤정 4 멘티에게 감사드립니다.  이 4명이 아니였다면 이러한 좋은 자료는 나오지 못했을 겁니다.

프리젠테이션이 다루는 내용은 다음과 같습니다.

Android 이해

  • 구글이 꿈꾸는 Android의 미래 (Modu 사 특허 인수와 Android@Home)
  • Binder ( Broker 패턴 )과 Intent

오픈소스 그리고 사례

  • Simple Framework
  • Logcat보다 Microlog4Android
  • 불편하지 않은 화면 갱신 (Publisher-Subscriber)

분석 방법

  • Localytics로 사용자 행동 패턴 분석
  • STAN을 이용한 Android App 분석방법

이번 발표는 소프트웨어 마에스트로 멘토로 활동하면서, 멘티들과 같이 만들어 낸 작품입니다.   비록 여러가지 상황(취업, 학업등)으로 모든 멘티가 다 2단계에 진출은 하지 못했지만, 지금도 열정을 내뿜으며 같이 성과를 만들어내고 좋은 팀웍을 유지하고 있습니다.

지표란 직접 경험을 하지 않아도 현재의 상황을 알수 있는 도구를 말합니다. 옛날 제주도에서는 식수가 귀해 빗물을 식수로 사용을 했습니다.  빗물의 오염도를 파악하기 위한 지표로, 개구리 (숫놈끼리만 넣거나, 암놈끼리만 넣거나)들을 넣었다고 합니다.

개구리 들이 벌레들을 잡아먹어 물이 항상 청결한 상태를 유지할 수 있었으며, 또한 개구리의 생존 여부로 물 오염도를 파악을 할수 있기 때문입니다.

일전에 소프트웨어 품질을 판단하는 지표로,  1000 피트의 뷰 라는 글을 소개해 드렸습니다.    너무 상세하지도 않고, 너무 추상화되어 있지도 않은 그 사이의 뷰를 1000 피트의 뷰라고 불렀습니다.

이러한 지표중 하나로, 예전 저의 포스트에서  Dependency Structure Matrix (DSM) 을 소개해 드렸습니다.

이번 포스트는 이러한 연장선상으로 Clean Code로 유명하신 Robert C. Martin (줄여서 Uncle. Bob)님이  만드신 Instability/Abstractness Graph 하나를 설명해 드리고자 합니다. (이 그래프에 대해 국내에 명확하게 소개된 자료가 없어서,  꼭 여러분에게 공유를 해드릴려고 합니다. )

이 포스트를 읽기 이전에  Bob 삼촌이 발표하신 패키지 구조의 원칙들(Principles of Package Architecture) 을 읽어보시거나, 또는 저의 이전 포스트인 Dependency를 관리하는 방안 을 읽어보시길 바랍니다.

그림 1. Bob 삼촌의 – Instability , Abstractness 그래포

 Uncle Bob의 지표는  Instability와 Abstractness 두 개에 대해 이해를 하셔야 합니다.  물론 여기에 추가적인 지표를 더한 변종(Variant) 들도 있지만, 이 두 가지 개념을 확실히 이해하실 필요가 있습니다.

계속 읽기

여러분이 프로그래머라면, 여러분의 관리자나 동료 또는 사용자에게 지금 하고 있는 업무의 예측 결과를 알려 주어야 합니다. 그렇게 해야 그들이 목적을 달성하는 데 필요한 시간, 비용, 기술 등을 정확하게 이해할 것입니다.
정확히 예측하려면 예측에 대한 기술을 배우는 것이 가장 중요합니다. 첫째로, 예측이란 무엇이고, 그것이 어떻게 사용되는지 배워야 합니다. 이상하게 들릴 수 있겠지만,  많은 프로그래머와 프로젝트 관리자들이 예측이 무엇인지 정확히 알고 있지 못합니다.

다음에 나오는 프로그래머와 프로젝트 관리자의 대화는 전혀 이상한 것이 아닙니다.

  • 프로젝트 관리자: 이 기능을 개발하는 데 얼마나 걸릴까요?
  • 프로그래머: 한 달이면 됩니다.
  • 프로젝트 관리자: 너무 길어요. 일주일 안에 완료해야 합니다.
  • 프로그래머: 적어도 3주는 필요할 것 같은데요.
  • 프로젝트 관리자: 2주까지는 시간을 드릴 수 있을 것 같습니다.
  • 프로그래머: 네, 좋습니다. 2주로 하죠.

프로그래머는 결국 프로젝트 관리자가 만족하는 선에 맞춰 예측하고 있습니다. 하지만 이것은 프로그래머가 예측치를 제공한 것이기 때문에 프로젝트 관리자는 프로그래머
에게 책임을 전가할 것입니다. 이 대화에서 무엇이 잘못되었는지 파악하려면 예측, 목표, 커밋먼트라는 세 단어를 정의해야 합니다.

계속 읽기

저는 원하는 것을 말하지 않아도 될만큼 만족하고 있는 고객을 만나본 적이 없습니다.   대부분 그들은 엄청나게 세세한 부분까지 이야기 합니다.  문제는 고객들이 항상 모든 진실을 이야기하지 않는다는 것입니다. 그들은 보통 거짓말을 하지 않습니다만,  고객의 관점에서 말할 뿐 개발자의 관점으로는 이야기 하지 않습니다.  그들은 그들만의 용어를 사용합니다. 그들은 중요한 세부사항들은 생략합니다.  그들은 마치 여러분도 그들처럼 그 회사에서 20년동안 근무했다고 생각하는 것 같습니다.

거기에다가 많은 고객들이 처음에는 정말로 원하는 것이 무엇인지 모른다는 사실까지 더해집니다!   고객들중 일부는 ” 큰 그림”을 파악하고 있을 수도 있겠지만, 그들이 보고 있는 “큰 그림”에 대한 세부사항을 효과적으로 전달할 수 있는 경우는 흔치 않습니다. 다른 사람들은 전체그림에 대해서는 얕은 지식을 가졌을 수도 있지만, 그들이 원하지 않는 것이 무엇인지를 알고 있습니다.

그러므로, 무엇을 원하는지에 대한 전체의 진실을 여러분에게 말해주지 않는 누군가에게 어떻게 소프트웨어 프로젝트를 제공할 수 있겠습니까?  그것은 매우 간단합니다. 그들과 더 많이 접촉해야 합니다.

계속 읽기

특히 많은 사용자들을 위한 경우, API 설계는 어렵습니다. 만약 여러분이 수 백에서 수 천의 사용자들이 사용할  API 를 설계한다면, 미래에 이것이 얼마나 바뀔 것인지, 그리고 변경 사항이 클라이언트 코드를 손상시킬 수 있는지 여부를 고려해야 합니다. 그 이상으로, 여러분은 API 사용자가 여러분에게 어떻게 영향을 미칠지 생각해야 합니다.

만약에 여러분의 API 클래스 중 하나가 내부적으로 자신의 함수들 중에 하나를 사용한다면, 사용자가 여러분의 클래스의 서브클래스를 만들고 오버라이드override 할 수 있으며, 그리고 그것은 재앙이 될 수 있다는 것을 꼭 명심해야 합니다. 몇몇 사용자들이 그 메소드를 서로 다른 의미로 받아들였기 때문에 여러분은 그것을 바꿀 수 없을지도 모릅니다. 메소드 내부 구현에 대한 여러분의 향후 선택은 사용자들이 이를 얼마나 받아들여 줄 수 있느냐에 달려 있습니다.

API 개발자들은 다양한 방법으로 이러한 문제들을 해결하지만, 가장 쉬운 방법은 API 를 봉쇄하는 것입니다. 만약 여러분이 자바 환경에서 작업한다면, 대부분의 클래스와 메소드를 final 로 선언하는 유혹에 빠질 수도 있습니다. C# 환경에서는, 여러분의 클래스와 메소드들을 sealed 로 선언해 버릴 수도 있습니다. 여러분이 어떤 개발 언어를 사용하든 간에, 행위를 오버라이드하거나 이후에 여러분의 선택을 제약하도록 코딩하는 것을 막기 위해 싱글턴 패턴이나 정적 팩토리 메소드를 이용해 API를 제공하고자 할 것입니다. 이 모든 것들이 합리적으로 보입니다만, 진짜로 그렇습니까?

지난 십년 동안, 우리는 점차 단위 테스트가 실전에 매우 중요한 부분이라는 사실을 깨달았지만, 이런 교훈이 업계에 완벽하게 확산되지는 못했습니다. 그 증거는 우리 주위에 널려 있습니다. 타사의 API 를 사용하는 임의의 테스트 안된 클래스에 대한 단위 테스트를 하려고 하면, 여러분은 곤경에 빠질 것입니다. 여러분은 그 코드가 마치 접착체로 붙인 듯이 API 를 사용하고 있다는 것을 알게 될 것입니다. 그것이 API 클래스이고 그래서 여러분의 다른 코드와 API 가 상호작용 한다는 것을 알아챌 수 있도록 하는 방법도 없고, 그래서 테스트를 위한 반환값을 제공할 수 있는 방법도 없습니다.

계속 읽기

저에게 연례 행사가 된 PLoP / SPLASH 참가는 정말 뜻 깊은 행사가 될듯 합니다.

이번 Bootcamp 행사는,  Linda Rising이 개인적인 사정으로 참석을 못해 아쉬움이 컸습니다. 하지만 반사 이익으로 사상 최고의 맴버로 진행이 되었습니다 . Robert Hanmer, Joe Yoder, Rebecca Wirfs-Brock 님이 진행을 하셨습니다.  이전 2번의 워크샵과는 다르게 프리젠테이션이 많이 보강되었습니다.

작년에 있었던 Joshua Kerivsky 발표의 영향 때문인지, Christopher Alexander의 철학과 이야기들이 많이 보강되었고, Joe Yoder가 AsianPLoP에서 했던 패턴 라이팅까지 패턴을 가르키는데 종합 선물센트에 가까운 Bootcamp 였습니다.

거기다 일본 KEIO대학에서 대거 행사에 참여했는데, 다케시라는 분이 Learning Pattern Languages를 만들었다며 선물로 나누어 주었습니다. (같이 프로젝트를 한 토모라는 분이 “Learning Pattern”의 PDF 버전이 공유되어 있다고 하니, 추후 접수되는 대로 공유하겠습니다. 아마 지금 일본 분들은 고국으로 가느라  비행기에 있겠네요.)

계속 읽기

스터디 그룹 언어 패턴 Sprit (정신) 편에 이어 Atmosphere (분위기) 편을 나누고자 합니다. ( 이 포스트를 쓸수 있게 흔쾌히 허락해준 김민수, 장성환, 이원희, 채경훈님의 지식 나눔에 정말 감사를 표합니다.)

Atmosphere (분위기) 편

스타벅스의 CEO Howrad Schultz는 그의 저서에서 편안한 만남의 장소의 중요성을 언급하면서 미국에서 사적인 교류의 시간이 줄어들고 있다고 지적했다. 1990년대 들어서 커피숍이 미국인의 사교의 장소로써 중요한 역할을 차지 하게 되었다. 이러한 장소는 집이나 회사의 일에 간섭 받지 않는 “제 3의 장소” 역할을 담당했기 때문이다.

이번 파트부터는 Atmosphere(분위기,장소)에 관한 이야기이다. 분위기나 장소의 선정도 스터디를 오래 이끄는 데 필수적인 요소이다. 큰 장소를 선정하고 그 장소내의 분위기 자리배열방법, 온라인 공간을 만드는 것에 대해 나누고자 한다.

계속 읽기

여러분에게 의미있는 패턴들을 공유해서 무척 기쁩니다.  패턴을 활용한 리펙터링 (Refactoring to Patterns)이라는 서적을 통해 우리나라에 알려진 Joshua Kerievsky의 스터디 그룹 패턴 언어를 번역은 아니어도 약식을 통해 편역을 해 공개해 드립니다.

삼성 소프트웨어 맴버십 후배이자, 소프트웨어 마에스트로 멘티인  김민수, 장성환, 이원희, 채경훈님에게 정말 감사드립니다.  정말 이 4친구에게 감사의 메세지를 보내며, 지식 나눔에 정말 감사를 표합니다.  훗날  따로 이 친구들에 대해 포스팅을 하도록 하겠습니다.

또한 이 편역된 자료를 다듬어 준  EVA 식구 분들에게 감사드립니다. 아무런 댓가 없이 열심히 다듬어 주셔서 감사드립니다.

소프트웨어 설계가 아니라. 스터디를 성공적으로 이끄는 패턴이라 의아해 하시는 분이 있을지 모르지만, 모든 것들이 사람이 모여 만드는 결과 이므로 사내 동호회나 커뮤니티에서 스터디를 이끄시는 분에게는 도움이 될듯 합니다.

이글을 읽기 전  2010년 PLoP에서Joshua Kerievsky가 발표한 “A Timeless way of Communicating”을 보시면 여러므로 도움이 되실 듯 합니다.

이 자료에 대한 모든 권한은 1차적으로 Joshua Kerievsky에게 있으며, 편역된 이 post의 권한 김민수, 장성환, 이원희, 채경훈 님에게 있습니다. 사용하실 분이 있으면, 위 네 분에게 문의해서 답신을 드리겠습니다.

계속 읽기

Fearless Change란 조직의 변화를 이끌어내고, 사람과 함께 소통하게 만드는 패턴입니다. 물론 이 패턴들도 상당히 장,단점이 있어서, 적절히 활용하시는게 바람직합니다. Fearless Change 패턴을 만들어 낸, Linda Rising 님의 성품과 사람을 이끌어 내는 힘은 정말 존경받을 만한 일입니다. 현종님의 경험이 담긴 Fearless Change를 공개하겠습니다!!   이 자료의 모든 저작권은 김현종 님에게 있습니다.  또한 EVA 이름으로 일전에 마이크로 소프트웨어에 기고한 글들을 […]

Framework Engineering  발표자료를 약간 업데이트 했습니다. Framework 전문가들을 서두에 추가하고, 업적들을 나열했습니다. Team 운영에 관해서 Cross Functional Team의 내용 추가 .NET Framework의 Break Changes를 일부 업데이트 했습니다. 상업적으로 강의나 발표자료, 출판용으로 사용을 금지합니다. 다만 원저작자와 출처를 명시해 주시는 조건과, 원 저작자의 동의하에 비 상업적 용도로 사용하실수 있습니다.