이 분은 Object Mentor 의 리더이자, Clean Code의 저자인 Bob 삼촌 (Uncle Bob – Robert C. Martin) 의 글이 “모든 프로그래머가 알아야할 97가지” 에 실려 있습니다.
저도 사실 뭔가 재미난 이야기를 해 줄거라고 했는데… 저희에게 너무나도 익숙한 객체지향의 중요한 원칙인 SOLID 의 S인 SRP를 이야기를 하셨네요.
익숙하지만 정말 중요한 원칙인 SRP 이야기를 다시 한번 들어보시길 바랍니다.
Single Responsibility Principle written by Uncle Bob
좋은 설계를 위한 가장 기본적인 원칙 중 하나는 다음과 같습니다.
동일한 이유로 변경되는 것들은 함께 모으고, 서로 다른 이유로 변경되는 것들은 분리시킨다.
이 원칙은 종종 단일 책임의 원칙(Single Responsibility Principle, SRP)이라고도 알려져 있습니다. 한마디로 말해서, 하나의 서브시스템, 모듈, 클래스, 또는 심지어 함수에 대해서도 한 가지 이상의 변경 이유가 있어서는 안 된다는 것을 의미합니다.
특히 많은 사용자들을 위한 경우, API 설계는 어렵습니다. 만약 여러분이 수 백에서 수 천의 사용자들이 사용할 API 를 설계한다면, 미래에 이것이 얼마나 바뀔 것인지, 그리고 변경 사항이 클라이언트 코드를 손상시킬 수 있는지 여부를 고려해야 합니다. 그 이상으로, 여러분은 API 사용자가 여러분에게 어떻게 영향을 미칠지 생각해야 합니다.
만약에 여러분의 API 클래스 중 하나가 내부적으로 자신의 함수들 중에 하나를 사용한다면, 사용자가 여러분의 클래스의 서브클래스를 만들고 오버라이드override 할 수 있으며, 그리고 그것은 재앙이 될 수 있다는 것을 꼭 명심해야 합니다. 몇몇 사용자들이 그 메소드를 서로 다른 의미로 받아들였기 때문에 여러분은 그것을 바꿀 수 없을지도 모릅니다. 메소드 내부 구현에 대한 여러분의 향후 선택은 사용자들이 이를 얼마나 받아들여 줄 수 있느냐에 달려 있습니다.
API 개발자들은 다양한 방법으로 이러한 문제들을 해결하지만, 가장 쉬운 방법은 API 를 봉쇄하는 것입니다. 만약 여러분이 자바 환경에서 작업한다면, 대부분의 클래스와 메소드를 final 로 선언하는 유혹에 빠질 수도 있습니다. C# 환경에서는, 여러분의 클래스와 메소드들을 sealed 로 선언해 버릴 수도 있습니다. 여러분이 어떤 개발 언어를 사용하든 간에, 행위를 오버라이드하거나 이후에 여러분의 선택을 제약하도록 코딩하는 것을 막기 위해 싱글턴 패턴이나 정적 팩토리 메소드를 이용해 API를 제공하고자 할 것입니다. 이 모든 것들이 합리적으로 보입니다만, 진짜로 그렇습니까?
지난 십년 동안, 우리는 점차 단위 테스트가 실전에 매우 중요한 부분이라는 사실을 깨달았지만, 이런 교훈이 업계에 완벽하게 확산되지는 못했습니다. 그 증거는 우리 주위에 널려 있습니다. 타사의 API 를 사용하는 임의의 테스트 안된 클래스에 대한 단위 테스트를 하려고 하면, 여러분은 곤경에 빠질 것입니다. 여러분은 그 코드가 마치 접착체로 붙인 듯이 API 를 사용하고 있다는 것을 알게 될 것입니다. 그것이 API 클래스이고 그래서 여러분의 다른 코드와 API 가 상호작용 한다는 것을 알아챌 수 있도록 하는 방법도 없고, 그래서 테스트를 위한 반환값을 제공할 수 있는 방법도 없습니다.
12월 3일 있던 한국 커뮤니티 데이에서 김현종님이 발표한 Fearless Change 발표자료입니다.
현종님이 직접 조직에서 체험한 Fearless Change 이야기가 많은 도움이 되셨는지 모르겠습니다.
연차가 올라가면서 정치는 소프트웨어를 만드는데 아주 큰 영향을 미친다는 것을 다들 서서히 깨닫으시리라 믿습니다.
사람들의 성향을 파악하고, 그에 맞게 점진적으로 조직을 바꿔나갔던 현종님의 경험담이 잘 전달되었는지 모르겠네요.
박현철 이사님으로 부터 정말 즐거운 메일이 왔습니다.
일전에 Meet the Architect라는 세미나를 진행해 주셨고, 정말 많은 가르침과 깨달음을 주셨던 박현철 이사님께서 Scrum 세미나를 진행해 주십니다.
산전 수전 다 겪으시고, 풍부한 컨설팅 경험을 가지신 이사님께서 Scrum 세미나라니. 단순히 스터디가 아니라, 현업의 목소리를 들려 주실 것 같습니다.
일전에 Meet the Architect 세미나로 감명을 받으신 분이라면, 한번 다시 찾아 뵙는 것이 어떨까요?
100명 선착순이니 서두르셔서 예약하셔야 될거 같습니다.
세미나 주제 : “Scrum 네~ 이놈!“
부제 : “도(道)를 닦기 위한 Scrum인가? 프로젝트 성공을 위한 Scrum인가?” , “기존 방법론은 방법론이 나빠서 실패하고, Scrum은 사람이 나빠서 실패한다?”
“당신이 Scrum을 진정 좋아한다면, Scrum의 잠재적인 문제를 얼마나 고민했고, 실제 상황에서 이들을 극복하기 위해 얼마나 시도했고 발전시켜왔는가? 당신이 Scrum을 진정 가치가 있다고 생각한다면, Scrum으로 무엇을 했고, 어떤 성과가 있었는가? 도대체… 당신이 진정 Scrum을 좋아한다고, 가치가 있다고 말할 수 있는가?”
얼마전 이대엽님이 도메인 주도 설계 (Domain Driven Design) 라는 명서를 번역해 주셨습니다. 저 역시 구매를 했었고, DDD가 가져오는 철학이나 사상은 정말 훌룡합니다.
왜 이런 명서가 이제 번역될수 밖에 없는지 현실을 알고 있지만, 정말 슬픕니다.
POSA나 DDD와 같은 명서들은 번역을 한다는 것의 거의 희생에 가깝습니다.
사실 역자 입장 에서는 적절한 어휘 선정과, 국내 개발자의 시선에 맞게 레벨을 조정하기 위해 각주를 다는등 여러가지 노력이 필요합니다.
또한 책이 많이 팔릴지도 의문이고, 이미 읽을만한 분은 다 읽었다고 생각이 들고, 나의 안티를 양성하지 않을까 고민이 됩니다.
실례로, 몇몇 출판사를 통해 “명서를 왜 이렇게 번역했느냐?”라며 여러가지 공격을 당한 사례들을 종종 들었기에 쉽게 움직이지 못하는 것도 사실입니다.
이러한 상황에서도 DDD가 이 세상에 나오게 해주신 이 대엽님과 여러 고생해 주신 분들에게 감사를 드립니다.
다시 본론으로 돌아와 DDD는 고객과 개발자/아키텍트 간에 대화를 나눌수 있는 좋은 도구입니다.
패턴 계의 철학을 생각해 보면, 모든 상황에 만능인 솔루션은 없다. 단지 상황에 맞는 해결책이 있다는 것을 생각해 볼 필요가 있습니다. 그러기에 해당 Context들이 대부분 도메인과 밀접한 연관이 있고, DDD의 초안이 PLoP 에서 첫 데뷔를 했기 때문에 역시 그 본류는 패턴의 철학과 맞 닿아 있는 방법입니다.
그럼 DDD를 프로젝트에 적용하기 이전에, 고려해야 할 것들 이야기 해보고자 합니다. 어떠헌 프로세스, 툴들에게도 동일하게 적용된느 철학입니다. 맹목적인 추종보다 결국 상황에 맞는 솔루션이라는 것을 기억해 주셔야 됩니다.
이번 저자 워크샵은 정말 힘든 강행군의 연속이었습니다.
PLoP 2011의 의장인 Lise Hvatum 과 2일에 거쳐 패턴을 같이 다듬었습니다. 사실 이번 PLoP에는 저희가 바쁜 일정에 논문을 잘 쓰지 못해서 논문을 같이 다듬는 Writing Group으로 배정을 받았는데, 오히려 많은 것을 배운거 같습니다.
같이 논문을 써준 김 지원님이 같이 간 덕분에 외롭지 않고, 이래 저래 정리한 내용도 2배로 늘어났습니다. 
결과적으로 좀더 Clear하게 그리고 Simple 하게 전체적으로 패턴을 바꾸었습니다. 첫째날 차 유리가 깨지고 지원이가 노트북을 읽어 버리는 바람에 사고 수습하느라 하루가 날라가 버리고, 남은 2일동안 강행군을 펼쳤고, 마지막날 새벽 4시에 겨우 마쳐서 최종본을 보냈슴니다.
지원가 맘고생도 많았지만, 이 잃어버린 노트북만 아니였어도.. 이렇게 고생을 하지않았을 텐데… 마지막날에 발표한 자료가 pdf 로 변환하면서 몇몇이 깨져버려 이래 저래 고생을 가장 많이한 PLoP 입니다.
Lise에게 보여주니, 새벽 4시에 온 메일을 보고 놀랐다고,정말 용감했다고 하더라구요! 좀더 명확하고 간결해졌다고 피드백을 받았습니다.
저자 워크샵
저자 워크샵이 무엇인지 모르시는 분은 제가 일전에 포스팅 한 저자 워크샵 데모 포스트를 보시고읽어보시면 좋을듯 합니다.
(중앙에 있는 분이 PLoP 11 Chair이자 , 저희 논문 Shepherd였던 Lise Hvatum , 그리고 오른쪽에 있는 분이 AsianPLoP의 리더이자, 와세대 대학의 조교수이신 Hironori Washizaki 입니다.)
실제 저희 워크샵에서 받은 내용을, 지원이가 잘 정리해 주었습니다. 추후 mp3를 듣고 더 업데이트 할 생각입니다.
저에게 연례 행사가 된 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 버전이 공유되어 있다고 하니, 추후 접수되는 대로 공유하겠습니다. 아마 지금 일본 분들은 고국으로 가느라 비행기에 있겠네요.)
PLoP 11 / SPLASH에 다녀오겠습니다. 갑자기 쌩뚱맞지만, 이제 저에게는 연례 행사가 되었답니다. 저의 성장에 큰 밑거름이 되준 PLoP에 다녀와서 많은 정보를 공유하겠습니다.
또한 이번 학회는 별로 외롭지 않은 것이 EVA팀의 김지원군 역시 회사 지원을 받아 같이 가게 되었습니다. 포스팅을 2배로 할수 있고, 곧 더 많은 정보를 전달해 드릴수 있어서 정말 기쁩니다. 전 아마 이 학회 다녀오면 몇일간은 잠을 못자며 정리하느라 보낼 수도 있습니다.
작년 2010년 PLoP에 다녀와서 남긴 포스트 입니다. 물론 더 있지만 굵직한 것 위주로 정리해 봤습니다. (PLoP 에 대한 더 많은 정보를 아시고 싶으시면, https://arload.wordpress.com/tag/plop/를 보시면 될듯 합니다.)
스터디 그룹 언어 패턴 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의 권한 김민수, 장성환, 이원희, 채경훈 님에게 있습니다. 사용하실 분이 있으면, 위 네 분에게 문의해서 답신을 드리겠습니다.
Architecture 101 