일전에 약속을 드렸던 것처럼 Fault Tolerance 패턴 자료를 공유드립니다. 고 가용성이라는 것이 서버쪽에서는 동일한 요소를 두개 주는 이중화라는 기법으로 확보가 가능하지만, 자동차나 프론트엔드, 모바일쪽에서는 이중화 전략을 쓰기에는 한계가 많습니다. 소프트웨어 아키텍처 설계 과정을 준비하면서 만든 자료입니다. 저 역시 많은 선배님들의 지식을 가지고 성장했던 것처럼, 이 자료가 많은 동료와 후배분 들에게 미약하나마 도움이 되었으며 합니다. pdf로 […]
릴리즈 및 설치 프로세스에 대한 디버깅이 프로젝트가 종료되는 시점까지도 진행되지 못하는 경우가 많습니다. 어떤 프로젝트에서는 설치도구를 작성하는 일이 릴리즈 엔지니어에게‘필요악’으로 주어집니다. 리뷰나 데모는 모든 것이 잘 동작함을 보장하기 위해 수작업으로 수행하는 경우가 많습니다. 결과적으로 팀은 너무 늦어서 변경하지 못할때까지도 릴리즈 프로세스 및 릴리즈하는 환경을 경험하지 못합니다.
설치/릴리즈 프로세스는 첫 번째로 고객에게 보여지는 것입니다. 단순한 설치/릴리즈 프로세스는 신뢰할 만한(또는 최소한 디버깅하기 쉬운) 동작 환경을 갖는 첫 단계입니다. 릴리즈된 소프트웨어는 고객이 사용하는 것입니다. 릴리즈된 프로그램이 올바르게 설치되는 것을 보장할 수 없다면, 여러분은 제대로 소프트웨어를 사용하지 못한 고객으로부터 많은 질문을 받게 될 것입니다.
설치 프로세스가 있는 프로젝트로 시작하면 제품 개발 주기 동안 프로세스를 발전시킬수 있는 시간을 벌 뿐만 아니라, 설치를 좀 더 쉽게 할 수 있도록 애플리케이션 코드를 변경할 수 있는 기회를 얻게 됩니다. 설치 프로세스를 주기적으로 수행하고 테스트함으로써 여러분이 작성한 코드가 개발 환경이나 테스트 환경뿐 아니라 사용자의 환경에서도 동작한다는 것을 확인할 수 있습니다.
드디어 또 하나의 작품이 출간되었습니다.
아키텍트가 가 알아야 할 97가지에 이어 프로그래머가 알아야 할 97가지가 드디어 출간되었습니다.
여러 지인들이 의기투합해서 만든 작품으로, 오랜 시간이 걸려 드디어 빛을 보게 되었습니다. 정말 많은 분들이 고생을 해주셨구요. 10명이 넘게 번역 작업을 하느라 정말 고생이 많았습니다. :
특히 일정한 퀄리티가 나오도록 어려번 검수를 해주시느라 고생해 주신, 김수현 , 최현미 두 역자님에게 정말 감사드립니다.
저보다 더 많은 노력을 해주셔서, 최종 검수때 많이 편했습니다. 정말 두 분에게 고개 숙여 감사드립니다. 어떻게 보면 두 분의 이름이 1,2 역자로 먼저 나와야 하는데, 겸손하게 저에게 1역자를 주셔셔, 책임감이 크게 느껴집니다.
또한 베타리더 분들에게도 정말 감사드립니다. 오역을 많이 다듬어 주시고, 좀더 쉬운 용어로 바꾸는 작업을 해주셔서 이 분들이 아니였으면 정말 더 오래 걸렸을거 같습니다.
이전 소프트웨어 아키텍트가 알아야 할 97가지 보다 좀더 개발자에게 와 닿고 가슴을 적실 선배들의 조언들이 듬뿍 담겨 있습니다. 업계 최고의 아키텍트, 프로그래머, Agile 전문가들이 경험에 기반한 조언들입니다.
또한 특별 부록으로, 원서에는 없는 한국의 유명한 프로그래머들의 추가 에피소드가 실려 있습니다.
이 분은 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 가 상호작용 한다는 것을 알아챌 수 있도록 하는 방법도 없고, 그래서 테스트를 위한 반환값을 제공할 수 있는 방법도 없습니다.
얼마전 이대엽님이 도메인 주도 설계 (Domain Driven Design) 라는 명서를 번역해 주셨습니다. 저 역시 구매를 했었고, DDD가 가져오는 철학이나 사상은 정말 훌룡합니다.
왜 이런 명서가 이제 번역될수 밖에 없는지 현실을 알고 있지만, 정말 슬픕니다.
POSA나 DDD와 같은 명서들은 번역을 한다는 것의 거의 희생에 가깝습니다.
사실 역자 입장 에서는 적절한 어휘 선정과, 국내 개발자의 시선에 맞게 레벨을 조정하기 위해 각주를 다는등 여러가지 노력이 필요합니다.
또한 책이 많이 팔릴지도 의문이고, 이미 읽을만한 분은 다 읽었다고 생각이 들고, 나의 안티를 양성하지 않을까 고민이 됩니다.
실례로, 몇몇 출판사를 통해 “명서를 왜 이렇게 번역했느냐?”라며 여러가지 공격을 당한 사례들을 종종 들었기에 쉽게 움직이지 못하는 것도 사실입니다.
이러한 상황에서도 DDD가 이 세상에 나오게 해주신 이 대엽님과 여러 고생해 주신 분들에게 감사를 드립니다.
다시 본론으로 돌아와 DDD는 고객과 개발자/아키텍트 간에 대화를 나눌수 있는 좋은 도구입니다.
패턴 계의 철학을 생각해 보면, 모든 상황에 만능인 솔루션은 없다. 단지 상황에 맞는 해결책이 있다는 것을 생각해 볼 필요가 있습니다. 그러기에 해당 Context들이 대부분 도메인과 밀접한 연관이 있고, DDD의 초안이 PLoP 에서 첫 데뷔를 했기 때문에 역시 그 본류는 패턴의 철학과 맞 닿아 있는 방법입니다.
그럼 DDD를 프로젝트에 적용하기 이전에, 고려해야 할 것들 이야기 해보고자 합니다. 어떠헌 프로세스, 툴들에게도 동일하게 적용된느 철학입니다. 맹목적인 추종보다 결국 상황에 맞는 솔루션이라는 것을 기억해 주셔야 됩니다.
저의 블로그 성격과 맞지 않지만, 아시는 지인 분들을 추천해 주셨으면 합니다.
책 이름은 LINQ in action입니다. 통합 질의어라고 보시면 됩니다.
Microsoft는 Object, Dataset, SQL, XML을 LINQ라는 것을 통해 왠만한 데이터들을 다 얻어올 수 있습니다.
이로써 Data Access Object를 따로 구축해서 Data Repository의 변경을 흡수할려는 설계/구현등의 노력들이 많이 흡수됩니다. (물론 Microsoft의 Enterprise Library에서 제공하는 Data Access Application Block만의 장점이 따로 있는것은 확실하죠. )
설계쪽보다는 LINQ라는 것을 많이 사용하셨고, 풍부한 경험을 가지신 분으로 부탁드립니다.
다른 출판사보다 훨씬 더, 베타리더 분을 극진히 모실것을 약속드립니다. 맛있는 식사를 대접하는 것은 물론이고, 지앤선에서 출판된 책도 한권 무료로 드리고, LINQ in Action 나오면 또 드리도록 하겠습니다.
안녕하세요. 많은 분이 기다리고 기다리셨던 “아키텍트가 알아야할 97가지” 가 드디어 나왔습니다. 아직 정식 출간은 아니지만, 예판으로 판매중입니다.
노란북( 책 비교 사이트)에 올라온 “아키텍트가 알아야할 97가지”
이번 “97 아키텍트”는 혼자 어떠한 성과물을 만드는 것보다, EVA 라는 팀의 이름으로 만든 성과물이라는데 깊은 의미를 두고 싶습니다. 누군가 한 말이 생각나네요 ” 빨리가면 대의가 아니다. 대의이기 때문에 느리고, 오래걸린다…” 굳이 대의까지는 아니지만, 느리지만, 더 정교하고, 다양한 시선을 합하느라 더 오래 시간이 걸렸습니다. 베타리더 분들의 도움과 많은 분의 지원과 격려로 만들어진 작품입니다. 많이 홍보해주시고, 널리 퍼뜨려 주시길 부탁드립니다.
이름하여 “7인의 베타리더!! “ (7인의 사무라이를 살짝 바꾸었습니다.)를 다시 모집합니다.
출간을 앞두고 있는 모든 소프트웨어 아키텍트가 알아야할 97가지 에 이어 그 시리즈인 “모든 프로그래머가 알아야할97가지”의 베타리더분을 모집합니다. 저의 지인들로 구성된 Project 입니다.
대략적인 내용은 바로 직전 포스트인 “12인의 아키텍트가 말하는 아키텍트의 소양과 자세”와 거의 유사합니다. 다만 이게 프로그래머 버젼이라고 생각하시면 됩니다.
다른 출판사보다 훨씬 더, 베타리더 분을 극진히 모실것을 약속드립니다. 맛있는 식사를 대접하는 것은 물론이고, 베타리더분의 성함과 사진을 실어 드리겠습니다. (물론 본인이 희망하실 경우구요). 그리고 지앤선에서 출판된 책도 한권 무료로 드립니다. 🙂
그럼 신청포멧은 다음과 같습니다.
마소 (마이크로 소프트웨어 ) 5월호에 “EVA네가 들려주는 Fearless Change 두 번째 이야기“라는 주제로 글을 기고했습니다.
원래 4월에 실릴 예정이었으나, 이런 저런 내부 사정으로 5월에 실리게 되었습니다. 이미 저의 블로그를 구독하시는 분에게는 싱거운 자료지만, 자료 공유 차원에서 올립니다.
물론 기고한 글은 모두 저의 지식이 아니며, Linda Rising의 지식과 다양한 분야의 경험을 가진 저희 EVA팀의 지식으로 만들어진 자료입니다. 지식을 나누어 주신 EVA 식구 여러분 감사합니다. 전 단지 정리를 했을 뿐입니다.
EVA 팀이 없었다면 이렇게 좋은 자료가 나온다는 것은 불가능했을 겁니다. EVA팀 감사합니다. 다음과 같은 내용이 기고 되었습니다.
Architecture 101 