Your SlideShare is downloading. ×
0
소프트웨어 <br />아키텍트가<br />알아야 할 12/97가지<br />
2<br />Architect(ure)란?<br />Architect in Korea...<br />Architect를 위한 조언들.<br />
Architect(ure)<br />
어원으로 보는 Architect(ure)<br />Archi<br />First / Chief / Govern<br />Tect/Test <br />Build/Prove<br />
Architect?= GOD<br />
현업이 요구하는 기괴한 아키텍트의 역할.<br />http://vizend.tistory.com/37<br />
그 누구의 일도 아니면..<br />네 (아키텍트) 탓이오!!<br />
여러분이 만난 S/W Architect.<br />
아키텍트가알아야할12/97가지<br />
왜 우리에겐 이런 일이 발생할까?<br />
#조언 1 Mark Richards의 Vasa호 이야기<br />
Vasa호 이야기<br />스웨덴 왕실의 위엄을 <br />온 세계에 알리고 <br />덴마크와 동유럽을 침공하기 위해 <br />국왕이 직접Vasa호의 설계에 참여.<br />아돌프구스타프2세<br />
국왕으로 인해 변경된 요구사항<br />
결국은 ..<br />
사상 최대의 사망자? 왜?<br />배 출항식 탑승인원 구성<br />귀족 100명<br />선원 50명<br />수영을 못하는 귀족들! <br />대부분 익사!!<br />
오히려 다행!<br />덕분에, 전수식 후 <br />항해하기로 했던<br />선원과 군인 450명은 <br />목숨을 건짐.<br />
결론<br />Vasa호와 같이 <br />모든 요구사항을 충족시키려는 시도는 <br />궁극적으로 아무것도 수행할 수 없는 <br />불완전한 아키텍처를 만들게 됩니다<br />
재미난 이야기 ! <br />세계에서 제일 가는 배<br />-서버린 오브 더 씨 (Sovereign of the Sea)<br />여러 전투에서 승승장구<br />
반복되는 역사..<br />
#조언 2 - Randy Stafford의“아키텍팅이란 균형에 관한 것이다.”<br />
요구사항 정하기.<br />출처 -IEEE1471 Korean Extension – 소프트웨어 아키텍처 정의(안)<br />
 Quality AttributesWorkshop<br />P<br />
QAW Roadmap<br />
QAW Roadmap<br />
Context<br />단, QAW, ATAM은 구축하고 하느 시스템이 명확하고, <br />이해당사자들이 시스템을 <br />이해하고 있을 때 적용 가능하다. <br />
Context<br />이해 당사자들간의 정치관계를 조심해라.<br />또한 <br />투표권을 전체 팀원에 적절히 배분해라.<br />
#조언 3 – Alistair Cockburn요구사항이 명확하지 않을 때.걸어 다니는 해골로 시작해라<br />
Rainy Day..<br />고객도 나도 <br />무엇을 만들어야 할지 모를 때.<br />
사례.<br />경영 이론 시스템을 적용해<br />의사 결정 도구 시스템을 <br />구축하는 프로젝트<br />신사웅님- 요구사항이 명확하지 않을 때..<br />
문제 발생<br />
갈등 발생!!<br />진행과정을 리뷰 하면서, 갈등 시작<br />전산팀은 나름대로 요구사항 정리 후 개발<br />시연을 하게 되면 전혀 다른 요구사항이 발생<br />고객이 원하는 시스템이 아니었다는 결론<br /...
신사웅님의 해결책<br />커뮤니케이션 문제가 시급하다고 판단<br />업무별 커뮤니케이션 창구를 확정<br />실제 피드백을 받을 수 있는 단위로 요구사항을 잘게 쪼개어 리스트 확정<br />각 요구사항마다 완료일과 ...
상황정리.<br />고객의 입장에서는 최종 보이는 결과는 UI <br />실제 필요한 요구사항 파악 불가<br />QoS– (비기능적인 요구사항) 파악 불가<br />선정한 Framework의 사용성, 적합성 모름.<b...
Walking Skeleton<br />
걸어 다니는 해골.<br />Prototyping보다 한 단계 앞선 모델.<br />종단(예를 들면 UI~DB까지) 간을 오가며 수행되는 가벼운 구현체.<br />모든 호출 경로를 실험할 수 있게 작동하는 작은 시스템....
걸어 다니는 해골.<br />모든 종단을 다 관통하는 주요 시나리오를 몇 개 만들어라.<br />그러다 보면, 시스템의 외적/내적인 요구사항을 자연스럽게 도출할 수 있다.<br />
#조언 4 –  KevlinHenney“설계의 기준으로 불확실성을 사용해라!!”<br />
A와 B 사이..<br />A와 B 두 가지 선택 중 <br />하나를 결정하려고 시도하는 대신, <br />“A와 B 사이의 결정을 덜 중요하게 만들기 위해 어떻게 설계해야 할까?” <br />고민해라!!<br />
다른 의미<br />선택/결정에 따라 발생할 수 있는 비용이 있다면 그 비용을 줄이기 위해선 어떻게 해야 할까?<br />Cavin님  블로그- http://cavin.egloos.com/5078906<br />
즉..<br />선택한 최선의 전략이 <br />언제나 최초의 효율이나 <br />최선의 효율을 <br />유지 하지 않는다.<br />
실제 세계에서는..<br />시간, 환경, 하는 일 등이 <br />원인에 의해 효율적일 수 있는 <br />구간이 시시각각 달라진다.<br />
풀이.<br />최선을 확신치 못한다면,<br />굳이 하나로 밀고 가지 말아라!<br />그런 구간이 있다는 것을 <br />염두해라!<br />당장 의사결정을 <br />성급히 내릴 필요가 없다.<br />
당신의 아키텍쳐(결정)은 변한다.<br />어떤 컴포넌트(분할 또는 캡슐화)가 <br />결정에 의존적인 코드로부터 <br />쉽게 변화를 수용할 수 있게 <br />잘 나뉘어져 있는지 파악해라.<br />
변화를 수용할 수 없다면..(돌팔이 왈!)<br /><ul><li>이건 예외적인 경우야!!
어쩔 수 없는….
통계에 의하면 이게 가장 좋아!</li></li></ul><li>풀어 말하면.<br />당신의 결정(아키텍쳐)가<br />올바른지 알아보려면,<br />비용을 줄일 수 있게 <br />분할 가능한지 살펴봐라!<br />
#조언 5 – ErickDoernenburg“1000피트의 뷰를 가져라”<br />
높이 (30000 feet)봐야 할까?<br />
높이 봐야 할까?<br />
자세히 (0 feet) 봐야 할까?<br />
자세히 봐야 할까?<br />
3만 피트 vs 0 피트의 뷰.<br />
해결책은..적절한  1000 피트의 뷰<br />
xDepend(Ndepend, Xdepend, CDepend)<br />NDepend - http://www.xdepend.com<br />
또 하나의 도구– Code Metrics<br />Demo<br />
STAN (Structure Analysis for Java)<br />Demo<br />STAN - http://stan4j.com/eclipse/eclipse-integration.html<br />
Robert C. Martin의 그래프<br />
Instability<br /><ul><li>패키지의 안정성을 측정
다른 패키지에 영향을 미치지 않고,</li></ul> 해당 패키지를 쉽게 변경 수 있는가?<br /><ul><li>Instability I = Ce / (Ca+Ce)
Ce = Efferent Coupling (Outgoing Dependencies)
Ca = Afferent Coupling (Ingoing Dependencies )</li></li></ul><li>Instability<br />당신의 패키지를 <br />누군가 많이 쓰고 있다면<br />바꾸기 쉽지...
Abstractness<br />Interface(Abstract) 와 Concrete Class를 비교<br /> A = (#abstract classes / total # of classes)<br /><ul><li...
Total # class = abstract class + concrete class
0 이면 concrete class만 있다.
1 이면 abstract class만 있다. </li></li></ul><li>다시 보는 그래프<br />조금 더 abstract를 높여야 돼!<br />
그 외 용어<br /><ul><li>Tangled Complexity
순환 참조가 있어 Boundary를 깰 때
Cyclomatic Complexity
분기 문이 많아 hotspot이 될 가망성이 높은 곳</li></li></ul><li>경고!!!<br />환자의 외부 증상만 <br />고치는 의사가 되지 말자!!<br />이러한 정보는 좋은 가이드일뿐!!<br />숫...
#조언 6 – Mike Brown“구현 가능한 것만 설계해라”<br />
주어진 문제를 우아하게 해결하기..<br /><ul><li>정교한 설계와 추상화 적용
프로젝트에 신기술 적용
새로운 패턴 과 프레임워크 적용</li></li></ul><li>많은 부작용을 수반한다.<br /><ul><li>개발자의 새로운 학습곡선.
데모처럼 과연 신기술이 잘 될까?
개발자의 신뢰를 잃게 된다.
불필요한 위험요소를 수반.</li></li></ul><li>사례.<br />차세대 시스템 경험담<br />유명 컨설턴트 A와의 경험<br />
기술을 모르는 영업 상무<br />기술을 모르는 영업 상무 <br />비행기에서 유명 컨설턴트와 만나다.<br />CBD에 대해서 이야기를 나눔.<br />당신의 솔루션이 재사용, 확장 가능해 진다.<br />귀국 후 ...
전문가 A 컨설턴트와의 마찰!<br />새로운 신기술을 적용해야 밴더 사에 잘 보이겠지.<br />맞지 않는 패턴 적용<br />Enterprise Pattern을 임베디드 시스템에 적용.<br />정식 버전이 나오지 ...
결과!<br />PM은 왜 일정이 연기되냐며 개발자 윽박 지르기!<br />컨설턴트 조직은 계약만료 후 나 몰라라 사라짐.<br />결국 프로젝트 6개월 연기!<br />시스템 오픈 후 여기 저기 문제 떠짐.<br />
#조언 7 – Mark Ramm가장 큰 문제는 기술이 아니다.<br />
지금도 어디선가 실패하고 있는 프로젝트.<br /><ul><li>기술의 잘못된 선택?
Java대신 Ruby를 선택해서..
Linux 대신 Windows를 사용해서..
문제가 정말 어려워서?</li></li></ul><li>모든 것은..<br />It’s all about people.<br />사람에 관한 것이다.<br />구체적인 기법은 부록에 있는 <br />Fearless Ch...
대화를 해라.<br />대화의 기술<br />정면 대결이 아니라 대화라는 관점에서 접근해라<br />사람들의 장점을 고려하고 대화해라.<br />여러분의 태도가 올바로 갖춰진 후에만 대화를 시도해라<br />화가 나거나...
#조언 8 – Niclas Nilsson“반복 작업과 싸워라!”<br />
생산성을 저해하는 이유..<br /><ul><li>복제는 악이다.
반복되는 작업.</li></li></ul><li>계속되는 반복과의 싸움..<br />김국현의 낭만 IT - 후기<br />
Architect가 줄여줘야하는 반복 작업<br />전 Architect 입장에서 <br />개발자에게 <br />박수받을 만한 기법들을 <br />전달하겠습니다.<br />
EA의 간략한 소개.<br />UML 2.1  Full 지원<br />모델링 정보를 다양한 DBMS와 연동하여 저장가능<br />형식을 파괴하는 모델링 지원 <br />Use Case에서도 Class Diagram의 요...
EA의 장점.<br />강력한 코드 템플릿 생성 기능 <br />몇 가지 Plug-in 소개<br />Legacy System을 위한 역 공학<br />문서 자동 생성 템플릿 소개<br />통합 개발 환경 구축 방법 <...
82<br />Code Template <br />
1. StreoType생성<br />Setting – UML – Streotypes<br />83<br />
2. 클래스 설계 후 StreoType할당<br />84<br />
3. 메소드 속성에 맞는 태깅생성<br />예를 들어 현재 재고를 파악하는 메소드는Database에서 데이터를 가져오는 (Get)  타입인 경우.<br />85<br />
4. 코드 생성 탬플릿 작성<br />Settings – Code Generation Templates <br />86<br />생성할 코드 <br />입력<br />다양한 <br />언어 선택<br />생성할 코드 템...
스트레오 타입 코드 템플릿 추가<br />87<br />
스트레오 템플릿 추가<br />Import Section<br />DLL 이나  Namespace를 추가하는 부분<br />Operation Body<br />메소드 구현 부에 사용자 코드를 추가 함<br />88<br />
89<br />간단한 예 - OperationBody<br />%if opTag:"DataAccessType" =="get" %   //데이터를 얻어오는 쿼리<br />IDataReader reader = null;<b...
90<br />Reverse Engineering<br />
통합 개발 환경 구축하기<br />91<br />
통합 개발 환경 구축하기<br />92<br />
개발 환경 구축 – 프로세스로 디버깅 하기<br />93<br />
프로세스로 디버깅하기<br />94<br />
디버깅 내용을 Sequence Diagram으로생성<br />95<br />
디버깅 내용을 Sequence Diagram으로생성<br />96<br />
97<br />Documentation<br />
다양한 포멧의 문서 제공<br />98<br />
문서 – Class및 Sequece<br />99<br />
100<br />UNIT TESTING<br />
Unit Testing과 연동됨<br />현재 xUnit (JUnit, Nunit) 형태로 생성및 관리가 가능함.<br />다른 Unit Test는 Package Script로 연동가능.<br />101<br />
Visual Studio 내장 UnitTest셋팅법<br />102<br />
연동된 Unit Test<br />103<br />
문서 – Testing Report<br />104<br />
#조언 9 – Evan Cofsky“드월프, 엘프, 마법사 그리고 왕”<br />
사람의 유형.<br />
사람의 유형.<br />드워프- 근면한 일꾼, <br />동굴 속의 어두운 고독 속에서 <br />꾸준히 산출물을 만드는 자<br />엘프– 천부적인 재능<br />우아, 교양있으며, 다른 종족이 하지 못하는 마법을 만...
사람의 유형.<br />마법사 – 강력한 종족, <br />엘프와 달리 마법의 강력함과 속성을 깊이 파악해, 놀라운 능력을 발휘<br />왕 – 보잘 것 없는 왕<br />단, 다른 종족과 무엇을 해야 할지 아는 몽상가...
왕의 역할<br />왕 (아키텍트)는 모든 종족과 친해야 함<br />아키텍쳐가 하나의 캐릭터(팀원)에게만 흘러가지 않도록 균형을 맞추어야 함<br />한가지 퀘스트(도전과제)를 위해 모든 종족 (이해 당사자)를 이끌어...
왕의 역할<br />왕 (아키텍트)는 <br />모든 종족 (팀원)이 <br />한마음이 될수 있는 <br />퀘스트(좋은 아키텍처)를 만들어야 하며, <br />각 종족(팀원)이 서로 배워가며, <br />각자 적합한...
#조언 10 – 김동열“정경유착(政經癒着)”<br />
아키텍트의 정치<br />아키텍트는 비즈니스 목표에 맞는 시스템을 만들기 위해,기술과 관련된 수많은 의사결정을 하는 사람입니다.<br />이해관계자 사이에서 정당성(rightness), 타당성(rational)을 바탕으...
제품 영업 담당자<br />효과적인 마케팅과 판매활동을 통해 이윤을 창출해야 하는 "경제"적인 역할을 담당.<br />맨발로 지내온 아프리카 원주민에게 구두를 팔고, 에스키모 인에게 냉장고를 파는 영업인에게'사기 쳤다'...
Upcoming SlideShare
Loading in...5
×

05. 아키텍트가 알아야할 12 97가지

7,371

Published on

Published in: Technology
5 Comments
62 Likes
Statistics
Notes
No Downloads
Views
Total Views
7,371
On Slideshare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
179
Comments
5
Likes
62
Embeds 0
No embeds

No notes for slide

Transcript of "05. 아키텍트가 알아야할 12 97가지"

  1. 1. 소프트웨어 <br />아키텍트가<br />알아야 할 12/97가지<br />
  2. 2. 2<br />Architect(ure)란?<br />Architect in Korea...<br />Architect를 위한 조언들.<br />
  3. 3. Architect(ure)<br />
  4. 4. 어원으로 보는 Architect(ure)<br />Archi<br />First / Chief / Govern<br />Tect/Test <br />Build/Prove<br />
  5. 5. Architect?= GOD<br />
  6. 6. 현업이 요구하는 기괴한 아키텍트의 역할.<br />http://vizend.tistory.com/37<br />
  7. 7. 그 누구의 일도 아니면..<br />네 (아키텍트) 탓이오!!<br />
  8. 8. 여러분이 만난 S/W Architect.<br />
  9. 9. 아키텍트가알아야할12/97가지<br />
  10. 10.
  11. 11. 왜 우리에겐 이런 일이 발생할까?<br />
  12. 12. #조언 1 Mark Richards의 Vasa호 이야기<br />
  13. 13. Vasa호 이야기<br />스웨덴 왕실의 위엄을 <br />온 세계에 알리고 <br />덴마크와 동유럽을 침공하기 위해 <br />국왕이 직접Vasa호의 설계에 참여.<br />아돌프구스타프2세<br />
  14. 14. 국왕으로 인해 변경된 요구사항<br />
  15. 15. 결국은 ..<br />
  16. 16. 사상 최대의 사망자? 왜?<br />배 출항식 탑승인원 구성<br />귀족 100명<br />선원 50명<br />수영을 못하는 귀족들! <br />대부분 익사!!<br />
  17. 17. 오히려 다행!<br />덕분에, 전수식 후 <br />항해하기로 했던<br />선원과 군인 450명은 <br />목숨을 건짐.<br />
  18. 18. 결론<br />Vasa호와 같이 <br />모든 요구사항을 충족시키려는 시도는 <br />궁극적으로 아무것도 수행할 수 없는 <br />불완전한 아키텍처를 만들게 됩니다<br />
  19. 19. 재미난 이야기 ! <br />세계에서 제일 가는 배<br />-서버린 오브 더 씨 (Sovereign of the Sea)<br />여러 전투에서 승승장구<br />
  20. 20. 반복되는 역사..<br />
  21. 21. #조언 2 - Randy Stafford의“아키텍팅이란 균형에 관한 것이다.”<br />
  22. 22. 요구사항 정하기.<br />출처 -IEEE1471 Korean Extension – 소프트웨어 아키텍처 정의(안)<br />
  23. 23. Quality AttributesWorkshop<br />P<br />
  24. 24. QAW Roadmap<br />
  25. 25. QAW Roadmap<br />
  26. 26. Context<br />단, QAW, ATAM은 구축하고 하느 시스템이 명확하고, <br />이해당사자들이 시스템을 <br />이해하고 있을 때 적용 가능하다. <br />
  27. 27. Context<br />이해 당사자들간의 정치관계를 조심해라.<br />또한 <br />투표권을 전체 팀원에 적절히 배분해라.<br />
  28. 28. #조언 3 – Alistair Cockburn요구사항이 명확하지 않을 때.걸어 다니는 해골로 시작해라<br />
  29. 29. Rainy Day..<br />고객도 나도 <br />무엇을 만들어야 할지 모를 때.<br />
  30. 30. 사례.<br />경영 이론 시스템을 적용해<br />의사 결정 도구 시스템을 <br />구축하는 프로젝트<br />신사웅님- 요구사항이 명확하지 않을 때..<br />
  31. 31. 문제 발생<br />
  32. 32. 갈등 발생!!<br />진행과정을 리뷰 하면서, 갈등 시작<br />전산팀은 나름대로 요구사항 정리 후 개발<br />시연을 하게 되면 전혀 다른 요구사항이 발생<br />고객이 원하는 시스템이 아니었다는 결론<br />전산팀에서 아이디어를 고민해 제시해 달라!!<br />업무적인 갈등을 넘어 감정의 갈등으로..<br />
  33. 33. 신사웅님의 해결책<br />커뮤니케이션 문제가 시급하다고 판단<br />업무별 커뮤니케이션 창구를 확정<br />실제 피드백을 받을 수 있는 단위로 요구사항을 잘게 쪼개어 리스트 확정<br />각 요구사항마다 완료일과 매일 진행상항 공유<br />완료된 사항으로는 거의 실시간으로 확인 및 테스트를 할 수 있도록 변경.<br />
  34. 34. 상황정리.<br />고객의 입장에서는 최종 보이는 결과는 UI <br />실제 필요한 요구사항 파악 불가<br />QoS– (비기능적인 요구사항) 파악 불가<br />선정한 Framework의 사용성, 적합성 모름.<br />비즈니스 도메인에 대한 정보 예측 불가<br />구축 후 발생하는 여러 문제들을 파악 불가<br />
  35. 35. Walking Skeleton<br />
  36. 36. 걸어 다니는 해골.<br />Prototyping보다 한 단계 앞선 모델.<br />종단(예를 들면 UI~DB까지) 간을 오가며 수행되는 가벼운 구현체.<br />모든 호출 경로를 실험할 수 있게 작동하는 작은 시스템.<br />
  37. 37. 걸어 다니는 해골.<br />모든 종단을 다 관통하는 주요 시나리오를 몇 개 만들어라.<br />그러다 보면, 시스템의 외적/내적인 요구사항을 자연스럽게 도출할 수 있다.<br />
  38. 38. #조언 4 – KevlinHenney“설계의 기준으로 불확실성을 사용해라!!”<br />
  39. 39. A와 B 사이..<br />A와 B 두 가지 선택 중 <br />하나를 결정하려고 시도하는 대신, <br />“A와 B 사이의 결정을 덜 중요하게 만들기 위해 어떻게 설계해야 할까?” <br />고민해라!!<br />
  40. 40. 다른 의미<br />선택/결정에 따라 발생할 수 있는 비용이 있다면 그 비용을 줄이기 위해선 어떻게 해야 할까?<br />Cavin님 블로그- http://cavin.egloos.com/5078906<br />
  41. 41. 즉..<br />선택한 최선의 전략이 <br />언제나 최초의 효율이나 <br />최선의 효율을 <br />유지 하지 않는다.<br />
  42. 42. 실제 세계에서는..<br />시간, 환경, 하는 일 등이 <br />원인에 의해 효율적일 수 있는 <br />구간이 시시각각 달라진다.<br />
  43. 43. 풀이.<br />최선을 확신치 못한다면,<br />굳이 하나로 밀고 가지 말아라!<br />그런 구간이 있다는 것을 <br />염두해라!<br />당장 의사결정을 <br />성급히 내릴 필요가 없다.<br />
  44. 44. 당신의 아키텍쳐(결정)은 변한다.<br />어떤 컴포넌트(분할 또는 캡슐화)가 <br />결정에 의존적인 코드로부터 <br />쉽게 변화를 수용할 수 있게 <br />잘 나뉘어져 있는지 파악해라.<br />
  45. 45. 변화를 수용할 수 없다면..(돌팔이 왈!)<br /><ul><li>이건 예외적인 경우야!!
  46. 46. 어쩔 수 없는….
  47. 47. 통계에 의하면 이게 가장 좋아!</li></li></ul><li>풀어 말하면.<br />당신의 결정(아키텍쳐)가<br />올바른지 알아보려면,<br />비용을 줄일 수 있게 <br />분할 가능한지 살펴봐라!<br />
  48. 48. #조언 5 – ErickDoernenburg“1000피트의 뷰를 가져라”<br />
  49. 49. 높이 (30000 feet)봐야 할까?<br />
  50. 50. 높이 봐야 할까?<br />
  51. 51. 자세히 (0 feet) 봐야 할까?<br />
  52. 52. 자세히 봐야 할까?<br />
  53. 53. 3만 피트 vs 0 피트의 뷰.<br />
  54. 54. 해결책은..적절한 1000 피트의 뷰<br />
  55. 55.
  56. 56. xDepend(Ndepend, Xdepend, CDepend)<br />NDepend - http://www.xdepend.com<br />
  57. 57. 또 하나의 도구– Code Metrics<br />Demo<br />
  58. 58. STAN (Structure Analysis for Java)<br />Demo<br />STAN - http://stan4j.com/eclipse/eclipse-integration.html<br />
  59. 59. Robert C. Martin의 그래프<br />
  60. 60. Instability<br /><ul><li>패키지의 안정성을 측정
  61. 61. 다른 패키지에 영향을 미치지 않고,</li></ul> 해당 패키지를 쉽게 변경 수 있는가?<br /><ul><li>Instability I = Ce / (Ca+Ce)
  62. 62. Ce = Efferent Coupling (Outgoing Dependencies)
  63. 63. Ca = Afferent Coupling (Ingoing Dependencies )</li></li></ul><li>Instability<br />당신의 패키지를 <br />누군가 많이 쓰고 있다면<br />바꾸기 쉽지 않다.<br />Instability I = Ce / (Ca+Ce)<br />당신의 패키지가 다른 사람이 많이 쓴다면, <br />즉 Outgoing, Ce가 많다면, 여러분의 패키지는 변경하기 어렵다.<br />반대로 Outgoing하는 Ce가 적다면,여러분의 패키지는 쉽게 변경해도 된다.<br />즉 0.0에서 0.3이면 안정적인 버전, 0.7에서 1.0이면 불안정적인 상태다<br />
  64. 64. Abstractness<br />Interface(Abstract) 와 Concrete Class를 비교<br /> A = (#abstract classes / total # of classes)<br /><ul><li>Abstract class = interface, abstract다 포함
  65. 65. Total # class = abstract class + concrete class
  66. 66. 0 이면 concrete class만 있다.
  67. 67. 1 이면 abstract class만 있다. </li></li></ul><li>다시 보는 그래프<br />조금 더 abstract를 높여야 돼!<br />
  68. 68. 그 외 용어<br /><ul><li>Tangled Complexity
  69. 69. 순환 참조가 있어 Boundary를 깰 때
  70. 70. Cyclomatic Complexity
  71. 71. 분기 문이 많아 hotspot이 될 가망성이 높은 곳</li></li></ul><li>경고!!!<br />환자의 외부 증상만 <br />고치는 의사가 되지 말자!!<br />이러한 정보는 좋은 가이드일뿐!!<br />숫자에 의존하다가 <br />오히려 아키텍쳐가 무너진다.<br />
  72. 72. #조언 6 – Mike Brown“구현 가능한 것만 설계해라”<br />
  73. 73. 주어진 문제를 우아하게 해결하기..<br /><ul><li>정교한 설계와 추상화 적용
  74. 74. 프로젝트에 신기술 적용
  75. 75. 새로운 패턴 과 프레임워크 적용</li></li></ul><li>많은 부작용을 수반한다.<br /><ul><li>개발자의 새로운 학습곡선.
  76. 76. 데모처럼 과연 신기술이 잘 될까?
  77. 77. 개발자의 신뢰를 잃게 된다.
  78. 78. 불필요한 위험요소를 수반.</li></li></ul><li>사례.<br />차세대 시스템 경험담<br />유명 컨설턴트 A와의 경험<br />
  79. 79. 기술을 모르는 영업 상무<br />기술을 모르는 영업 상무 <br />비행기에서 유명 컨설턴트와 만나다.<br />CBD에 대해서 이야기를 나눔.<br />당신의 솔루션이 재사용, 확장 가능해 진다.<br />귀국 후 차세대 시스템 구축 <br />기존 시스템 유지보수에 지친 개발자들도 환호<br />개발자의 추천으로 전문가 A를 아키텍트로 섭외.<br />
  80. 80. 전문가 A 컨설턴트와의 마찰!<br />새로운 신기술을 적용해야 밴더 사에 잘 보이겠지.<br />맞지 않는 패턴 적용<br />Enterprise Pattern을 임베디드 시스템에 적용.<br />정식 버전이 나오지 않은 신기술을 적용<br />실시간성이 보장되어야 하는 시스템에서 첫 통신시 14초가 걸림.<br />개발자들 왈: “임베디드 시스템 특성을 몰라? … “<br />기존 기술에 익숙한 개발자들의 반발<br />무엇이 좋아질지 모르는데왜 바꿔?<br />과연 이렇게 잘게 나누면 좋아질까?<br />
  81. 81. 결과!<br />PM은 왜 일정이 연기되냐며 개발자 윽박 지르기!<br />컨설턴트 조직은 계약만료 후 나 몰라라 사라짐.<br />결국 프로젝트 6개월 연기!<br />시스템 오픈 후 여기 저기 문제 떠짐.<br />
  82. 82. #조언 7 – Mark Ramm가장 큰 문제는 기술이 아니다.<br />
  83. 83. 지금도 어디선가 실패하고 있는 프로젝트.<br /><ul><li>기술의 잘못된 선택?
  84. 84. Java대신 Ruby를 선택해서..
  85. 85. Linux 대신 Windows를 사용해서..
  86. 86. 문제가 정말 어려워서?</li></li></ul><li>모든 것은..<br />It’s all about people.<br />사람에 관한 것이다.<br />구체적인 기법은 부록에 있는 <br />Fearless Change를 참조.<br />
  87. 87. 대화를 해라.<br />대화의 기술<br />정면 대결이 아니라 대화라는 관점에서 접근해라<br />사람들의 장점을 고려하고 대화해라.<br />여러분의 태도가 올바로 갖춰진 후에만 대화를 시도해라<br />화가 나거나 짜증난 상태에서 대화하지 말아라<br />회의 시 침묵하는 사람들의 의견을 이끌어 내라.<br />특정 사람에게만 발언권이 모이지 않게 해라.<br />모든 사람의 관점을 다 들어보아라.<br />
  88. 88. #조언 8 – Niclas Nilsson“반복 작업과 싸워라!”<br />
  89. 89. 생산성을 저해하는 이유..<br /><ul><li>복제는 악이다.
  90. 90. 반복되는 작업.</li></li></ul><li>계속되는 반복과의 싸움..<br />김국현의 낭만 IT - 후기<br />
  91. 91. Architect가 줄여줘야하는 반복 작업<br />전 Architect 입장에서 <br />개발자에게 <br />박수받을 만한 기법들을 <br />전달하겠습니다.<br />
  92. 92. EA의 간략한 소개.<br />UML 2.1 Full 지원<br />모델링 정보를 다양한 DBMS와 연동하여 저장가능<br />형식을 파괴하는 모델링 지원 <br />Use Case에서도 Class Diagram의 요소들을 사용가능<br />다양한 언어를 지원 <br />C++, C#, Delphi, Java, VB, VB.NET, PHP, Python<br />강력한 코드 탬플릿 생성 기능<br />테스팅생성및 관리 (기존 Unit Testing 과 연동됨)<br />강력한 역공학 기능<br />다양한 Plug-in 지원<br />가장 저렴한 가격 1 Copy당 20만원 ~ 30만원 사이<br />80<br />
  93. 93. EA의 장점.<br />강력한 코드 템플릿 생성 기능 <br />몇 가지 Plug-in 소개<br />Legacy System을 위한 역 공학<br />문서 자동 생성 템플릿 소개<br />통합 개발 환경 구축 방법 <br />81<br />
  94. 94. 82<br />Code Template <br />
  95. 95. 1. StreoType생성<br />Setting – UML – Streotypes<br />83<br />
  96. 96. 2. 클래스 설계 후 StreoType할당<br />84<br />
  97. 97. 3. 메소드 속성에 맞는 태깅생성<br />예를 들어 현재 재고를 파악하는 메소드는Database에서 데이터를 가져오는 (Get) 타입인 경우.<br />85<br />
  98. 98. 4. 코드 생성 탬플릿 작성<br />Settings – Code Generation Templates <br />86<br />생성할 코드 <br />입력<br />다양한 <br />언어 선택<br />생성할 코드 템플릿 <br />Namespace, Class, Operation 등<br />스트레오타입별 템플릿을 지정<br />
  99. 99. 스트레오 타입 코드 템플릿 추가<br />87<br />
  100. 100. 스트레오 템플릿 추가<br />Import Section<br />DLL 이나 Namespace를 추가하는 부분<br />Operation Body<br />메소드 구현 부에 사용자 코드를 추가 함<br />88<br />
  101. 101. 89<br />간단한 예 - OperationBody<br />%if opTag:"DataAccessType" =="get" % //데이터를 얻어오는 쿼리<br />IDataReader reader = null;<br />%opReturnType% retVal = new %opReturnType%();<br />try<br />{<br /> // 1. Create the Database object, using the default database service.<br /> Database db = DatabaseFactory.CreateDatabase();<br />log.Debug("Create Database Factory");<br /> // 2. Create DB Command<br /> string sqlCommand = "$queryName";<br />dbCommand = db.GetStoredProcCommand(sqlCommand);<br />log.Debug("GetStoredProcCommand(" + sqlCommand + ")");<br /> ….<br />} %elseIfopTag:"DataAccessType" =="set"% //데이터를 쓰는 쿼리<br />DbConnection connection = null;<br />UInt32 retVal = 0;<br />try<br />{ …….. <br />89<br />
  102. 102. 90<br />Reverse Engineering<br />
  103. 103. 통합 개발 환경 구축하기<br />91<br />
  104. 104. 통합 개발 환경 구축하기<br />92<br />
  105. 105. 개발 환경 구축 – 프로세스로 디버깅 하기<br />93<br />
  106. 106. 프로세스로 디버깅하기<br />94<br />
  107. 107. 디버깅 내용을 Sequence Diagram으로생성<br />95<br />
  108. 108. 디버깅 내용을 Sequence Diagram으로생성<br />96<br />
  109. 109. 97<br />Documentation<br />
  110. 110. 다양한 포멧의 문서 제공<br />98<br />
  111. 111. 문서 – Class및 Sequece<br />99<br />
  112. 112. 100<br />UNIT TESTING<br />
  113. 113. Unit Testing과 연동됨<br />현재 xUnit (JUnit, Nunit) 형태로 생성및 관리가 가능함.<br />다른 Unit Test는 Package Script로 연동가능.<br />101<br />
  114. 114. Visual Studio 내장 UnitTest셋팅법<br />102<br />
  115. 115. 연동된 Unit Test<br />103<br />
  116. 116. 문서 – Testing Report<br />104<br />
  117. 117. #조언 9 – Evan Cofsky“드월프, 엘프, 마법사 그리고 왕”<br />
  118. 118. 사람의 유형.<br />
  119. 119. 사람의 유형.<br />드워프- 근면한 일꾼, <br />동굴 속의 어두운 고독 속에서 <br />꾸준히 산출물을 만드는 자<br />엘프– 천부적인 재능<br />우아, 교양있으며, 다른 종족이 하지 못하는 마법을 만들어 냄.<br />
  120. 120. 사람의 유형.<br />마법사 – 강력한 종족, <br />엘프와 달리 마법의 강력함과 속성을 깊이 파악해, 놀라운 능력을 발휘<br />왕 – 보잘 것 없는 왕<br />단, 다른 종족과 무엇을 해야 할지 아는 몽상가 (비전을 제시)<br />
  121. 121. 왕의 역할<br />왕 (아키텍트)는 모든 종족과 친해야 함<br />아키텍쳐가 하나의 캐릭터(팀원)에게만 흘러가지 않도록 균형을 맞추어야 함<br />한가지 퀘스트(도전과제)를 위해 모든 종족 (이해 당사자)를 이끌어, 같이 일할수 있도록 도와야 한다.<br />
  122. 122. 왕의 역할<br />왕 (아키텍트)는 <br />모든 종족 (팀원)이 <br />한마음이 될수 있는 <br />퀘스트(좋은 아키텍처)를 만들어야 하며, <br />각 종족(팀원)이 서로 배워가며, <br />각자 적합한 일을 할 수 있는 가이드 제시.<br />
  123. 123. #조언 10 – 김동열“정경유착(政經癒着)”<br />
  124. 124. 아키텍트의 정치<br />아키텍트는 비즈니스 목표에 맞는 시스템을 만들기 위해,기술과 관련된 수많은 의사결정을 하는 사람입니다.<br />이해관계자 사이에서 정당성(rightness), 타당성(rational)을 바탕으로 이해관계를 조율하고 설득해야함.<br />
  125. 125. 제품 영업 담당자<br />효과적인 마케팅과 판매활동을 통해 이윤을 창출해야 하는 "경제"적인 역할을 담당.<br />맨발로 지내온 아프리카 원주민에게 구두를 팔고, 에스키모 인에게 냉장고를 파는 영업인에게'사기 쳤다'고 이야기 하지는 않습니다. <br />오히려 새로운 시장을 개척했다고 말함.<br />
  126. 126. 사례.<br />아키텍트와 영업간의 이해관계가 맞을 경우.<br />
  127. 127. 영업 부장의 압력.<br />EJB 기반의 WAS <br />EJB와 관계형 기반의 DB 시스템에 유리<br />요구사항<br />CORBA도 넣어라<br />최신제품이니, 객체 지향 DB도 쓰자<br />결론 “넣긴 넣었다. 하지만..”<br />CORBA를 어디에 적용했는지 기억도 안남.<br />객체지향 DB일부만 적용<br />
  128. 128. 또 다른 Vasa호<br />미션이 완전히 동일한 시스템은 없다.<br />모든 시스템의 목표를 만족시켜줄 아키텍쳐, 솔루션은 존재하지 않는다.<br />만들수 있겠지만, 새로운 장애물이 나올경우 침몰하는 또다른Vasa호가 될 뿐이다.<br />
  129. 129. 결론.<br />아키텍트는<br />올바른 “정치”를 하기 위해, <br />정경유착의 고리를 끊고, <br />특정 제품에 자유로울 필요가 있습니다.<br />
  130. 130. #조언 11 – Dave Quick“소문자 i로써의 아키텍트”<br />
  131. 131. 개발자를 무시하는 아키텍트 유형<br />고객보다 요구사항을 더 잘 이해한다.<br />개발자를 자신의 아이디어를 구현하는 사람으로 본다<br />자신의 아이디어가 도전 받거나, 무시 당할 때 방어적으로 변한다.<br />
  132. 132. 왜 이렇게 되었나?<br />난 지금까지 성공 해왔다!!<br />사람들은 우리를 존경한다.<br />설계는 곧 나 자신이다.<br />
  133. 133. 올바른 자세를 갖는 방법<br />요구사항은 거짓말을 하지 않는다.<br />고객과 같이 일해라<br />팀에 집중해라.<br />팀은 자원이 아니다. <br />설계 협력자이며, <br />여러분의 진가를 인정하게 만들어 줄 사람들이다!!<br />
  134. 134. 올바른 자세를 갖는 방법<br />업무를 점검해라.<br />아키텍쳐가 각 요구사항을 어떻게 지원하는지 검증해라.<br />나 자신을 돌아봐라<br />팀원들이 여러분을 존경하고 있는가?<br />선의의 참여에 부정적으로 대답하지 않는가?<br />왜 그 사람이 나의 방식에 불응했을까?<br />
  135. 135. #조언 12 – ???“컨설팅과 사과 이야기”<br />
  136. 136. 컨설턴트와 컨설팅 받는 사람<br />컨설턴트는 이해당사자들 모두를 이해하고<br />어떠한 benefit을 줄수 있는지 설명해야 한다.<br />컨설팅 받는 사람은 <br />무조건 적인 저항보다는<br />더 도메인 전문가이니, 협상을 해 나가야 한다.<br />
  137. 137. 감사합니다.<br />
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×