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

More Related Content

What's hot

10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
10+ Deploys Per Day: Dev and Ops Cooperation at Flickr10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
John Allspaw
 
Network Protocol Testing Using Robot Framework
Network Protocol Testing Using Robot FrameworkNetwork Protocol Testing Using Robot Framework
Network Protocol Testing Using Robot Framework
Payal Jain
 
Hybrid automation framework
Hybrid automation frameworkHybrid automation framework
Hybrid automation framework
doai tran
 
[오픈소스컨설팅]클라우드기반U2L마이그레이션 전략 및 고려사항
[오픈소스컨설팅]클라우드기반U2L마이그레이션 전략 및 고려사항[오픈소스컨설팅]클라우드기반U2L마이그레이션 전략 및 고려사항
[오픈소스컨설팅]클라우드기반U2L마이그레이션 전략 및 고려사항
Ji-Woong Choi
 
WebSphere Application Server V8.5.5 Libertyプロファイルのご紹介 #jjug_ccc #ccc_r51
WebSphere Application Server V8.5.5Libertyプロファイルのご紹介 #jjug_ccc #ccc_r51WebSphere Application Server V8.5.5Libertyプロファイルのご紹介 #jjug_ccc #ccc_r51
WebSphere Application Server V8.5.5 Libertyプロファイルのご紹介 #jjug_ccc #ccc_r51
Takakiyo Tanaka
 
Postman. From simple API test to end to end scenario
Postman. From simple API test to end to end scenarioPostman. From simple API test to end to end scenario
Postman. From simple API test to end to end scenario
HYS Enterprise
 
Jenkins
JenkinsJenkins
[기본과정] 코드 테스트와 커버리지 기본 교육(개념)
[기본과정] 코드 테스트와 커버리지 기본 교육(개념)[기본과정] 코드 테스트와 커버리지 기본 교육(개념)
[기본과정] 코드 테스트와 커버리지 기본 교육(개념)
SangIn Choung
 
Understanding the GitOps Workflow and CICD Pipeline - What It Is, Why It Matt...
Understanding the GitOps Workflow and CICD Pipeline - What It Is, Why It Matt...Understanding the GitOps Workflow and CICD Pipeline - What It Is, Why It Matt...
Understanding the GitOps Workflow and CICD Pipeline - What It Is, Why It Matt...
Gibran Badrulzaman
 
infrastructure as code
infrastructure as codeinfrastructure as code
infrastructure as code
Amazon Web Services
 
Ch6 대용량서비스레퍼런스아키텍처 part.1
Ch6 대용량서비스레퍼런스아키텍처 part.1Ch6 대용량서비스레퍼런스아키텍처 part.1
Ch6 대용량서비스레퍼런스아키텍처 part.1
Minchul Jung
 
Test Automation Framework Designs
Test Automation Framework DesignsTest Automation Framework Designs
Test Automation Framework Designs
Sauce Labs
 
Python in Test automation
Python in Test automationPython in Test automation
Python in Test automation
Krishnana Sreeraman
 
SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성
SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성
SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성
CURVC Corp
 
1. 아키텍쳐 설계 프로세스
1. 아키텍쳐 설계 프로세스1. 아키텍쳐 설계 프로세스
1. 아키텍쳐 설계 프로세스
Terry Cho
 
Micro services Architecture
Micro services ArchitectureMicro services Architecture
Micro services Architecture
Araf Karsh Hamid
 
GitHub入門 手順編
GitHub入門 手順編GitHub入門 手順編
GitHub入門 手順編hideaki honda
 
Anatomy of a Continuous Integration and Delivery (CICD) Pipeline
Anatomy of a Continuous Integration and Delivery (CICD) PipelineAnatomy of a Continuous Integration and Delivery (CICD) Pipeline
Anatomy of a Continuous Integration and Delivery (CICD) Pipeline
Robert McDermott
 
サーバーレスでアンケートフォームを作ってみた
サーバーレスでアンケートフォームを作ってみたサーバーレスでアンケートフォームを作ってみた
サーバーレスでアンケートフォームを作ってみた
ryutakatori
 

What's hot (20)

Google Cloud で実践する SRE
Google Cloud で実践する SRE  Google Cloud で実践する SRE
Google Cloud で実践する SRE
 
10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
10+ Deploys Per Day: Dev and Ops Cooperation at Flickr10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
 
Network Protocol Testing Using Robot Framework
Network Protocol Testing Using Robot FrameworkNetwork Protocol Testing Using Robot Framework
Network Protocol Testing Using Robot Framework
 
Hybrid automation framework
Hybrid automation frameworkHybrid automation framework
Hybrid automation framework
 
[오픈소스컨설팅]클라우드기반U2L마이그레이션 전략 및 고려사항
[오픈소스컨설팅]클라우드기반U2L마이그레이션 전략 및 고려사항[오픈소스컨설팅]클라우드기반U2L마이그레이션 전략 및 고려사항
[오픈소스컨설팅]클라우드기반U2L마이그레이션 전략 및 고려사항
 
WebSphere Application Server V8.5.5 Libertyプロファイルのご紹介 #jjug_ccc #ccc_r51
WebSphere Application Server V8.5.5Libertyプロファイルのご紹介 #jjug_ccc #ccc_r51WebSphere Application Server V8.5.5Libertyプロファイルのご紹介 #jjug_ccc #ccc_r51
WebSphere Application Server V8.5.5 Libertyプロファイルのご紹介 #jjug_ccc #ccc_r51
 
Postman. From simple API test to end to end scenario
Postman. From simple API test to end to end scenarioPostman. From simple API test to end to end scenario
Postman. From simple API test to end to end scenario
 
Jenkins
JenkinsJenkins
Jenkins
 
[기본과정] 코드 테스트와 커버리지 기본 교육(개념)
[기본과정] 코드 테스트와 커버리지 기본 교육(개념)[기본과정] 코드 테스트와 커버리지 기본 교육(개념)
[기본과정] 코드 테스트와 커버리지 기본 교육(개념)
 
Understanding the GitOps Workflow and CICD Pipeline - What It Is, Why It Matt...
Understanding the GitOps Workflow and CICD Pipeline - What It Is, Why It Matt...Understanding the GitOps Workflow and CICD Pipeline - What It Is, Why It Matt...
Understanding the GitOps Workflow and CICD Pipeline - What It Is, Why It Matt...
 
infrastructure as code
infrastructure as codeinfrastructure as code
infrastructure as code
 
Ch6 대용량서비스레퍼런스아키텍처 part.1
Ch6 대용량서비스레퍼런스아키텍처 part.1Ch6 대용량서비스레퍼런스아키텍처 part.1
Ch6 대용량서비스레퍼런스아키텍처 part.1
 
Test Automation Framework Designs
Test Automation Framework DesignsTest Automation Framework Designs
Test Automation Framework Designs
 
Python in Test automation
Python in Test automationPython in Test automation
Python in Test automation
 
SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성
SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성
SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성
 
1. 아키텍쳐 설계 프로세스
1. 아키텍쳐 설계 프로세스1. 아키텍쳐 설계 프로세스
1. 아키텍쳐 설계 프로세스
 
Micro services Architecture
Micro services ArchitectureMicro services Architecture
Micro services Architecture
 
GitHub入門 手順編
GitHub入門 手順編GitHub入門 手順編
GitHub入門 手順編
 
Anatomy of a Continuous Integration and Delivery (CICD) Pipeline
Anatomy of a Continuous Integration and Delivery (CICD) PipelineAnatomy of a Continuous Integration and Delivery (CICD) Pipeline
Anatomy of a Continuous Integration and Delivery (CICD) Pipeline
 
サーバーレスでアンケートフォームを作ってみた
サーバーレスでアンケートフォームを作ってみたサーバーレスでアンケートフォームを作ってみた
サーバーレスでアンケートフォームを作ってみた
 

Viewers also liked

Career path for university students
Career path for university studentsCareer path for university students
Career path for university students
Jae keun Lee
 
하루 안에 페이스북 웹 앱 만들기
하루 안에 페이스북 웹 앱 만들기하루 안에 페이스북 웹 앱 만들기
하루 안에 페이스북 웹 앱 만들기YongHui Lee
 
Joyfl 창업이야기.ssul
Joyfl 창업이야기.ssulJoyfl 창업이야기.ssul
Joyfl 창업이야기.ssul
Suyeol Jeon
 
Sw 아키텍처와 sw 공학
Sw 아키텍처와 sw 공학Sw 아키텍처와 sw 공학
Sw 아키텍처와 sw 공학
영온 김
 
[H3 2012] 오픈소스로 개발 실력 쌓기
[H3 2012] 오픈소스로 개발 실력 쌓기[H3 2012] 오픈소스로 개발 실력 쌓기
[H3 2012] 오픈소스로 개발 실력 쌓기
KTH, 케이티하이텔
 
Framework Engineering 2.1
Framework Engineering 2.1Framework Engineering 2.1
Framework Engineering 2.1
YoungSu Son
 
스타트업 홍보의 이론과 실제 20130323
스타트업 홍보의 이론과 실제 20130323스타트업 홍보의 이론과 실제 20130323
스타트업 홍보의 이론과 실제 20130323YoonTaeSup
 
[NEXT] Android Profiler
[NEXT] Android Profiler[NEXT] Android Profiler
[NEXT] Android Profiler
YoungSu Son
 
아키텍트가 바라보는 Spring framework
아키텍트가 바라보는 Spring framework아키텍트가 바라보는 Spring framework
아키텍트가 바라보는 Spring framework
Haeil Yi
 
세미나 Spring mybatis
세미나 Spring mybatis세미나 Spring mybatis
세미나 Spring mybatis
Somang Jeong
 
Docker at Deview 2013
Docker at Deview 2013Docker at Deview 2013
Docker at Deview 2013
Jude Kim
 
김동건, 게임팅커가 되자, 2015년 데브캣 스튜디오 워크샵
김동건, 게임팅커가 되자, 2015년 데브캣 스튜디오 워크샵김동건, 게임팅커가 되자, 2015년 데브캣 스튜디오 워크샵
김동건, 게임팅커가 되자, 2015년 데브캣 스튜디오 워크샵
devCAT Studio, NEXON
 
좋은 디자이너, 나쁜 프로젝트매니저, 이상한 개발자
좋은 디자이너, 나쁜 프로젝트매니저, 이상한 개발자좋은 디자이너, 나쁜 프로젝트매니저, 이상한 개발자
좋은 디자이너, 나쁜 프로젝트매니저, 이상한 개발자Suyeol Jeon
 
5.yobi를 활용한 개발자 협업 및 배포 프로세스
5.yobi를 활용한 개발자 협업 및 배포 프로세스5.yobi를 활용한 개발자 협업 및 배포 프로세스
5.yobi를 활용한 개발자 협업 및 배포 프로세스NAVER D2
 
김충효, 10년째 같은 회사를 다니고 있습니다
김충효, 10년째 같은 회사를 다니고 있습니다김충효, 10년째 같은 회사를 다니고 있습니다
김충효, 10년째 같은 회사를 다니고 있습니다
devCAT Studio, NEXON
 
HTML5를 활용한 하이브리드 앱개발하기
HTML5를 활용한 하이브리드 앱개발하기HTML5를 활용한 하이브리드 앱개발하기
HTML5를 활용한 하이브리드 앱개발하기
정현 황
 
2.네이버 프론트엔드 김지태
2.네이버 프론트엔드 김지태2.네이버 프론트엔드 김지태
2.네이버 프론트엔드 김지태NAVER D2
 

Viewers also liked (18)

Career path for university students
Career path for university studentsCareer path for university students
Career path for university students
 
하루 안에 페이스북 웹 앱 만들기
하루 안에 페이스북 웹 앱 만들기하루 안에 페이스북 웹 앱 만들기
하루 안에 페이스북 웹 앱 만들기
 
Joyfl 창업이야기.ssul
Joyfl 창업이야기.ssulJoyfl 창업이야기.ssul
Joyfl 창업이야기.ssul
 
Sw 아키텍처와 sw 공학
Sw 아키텍처와 sw 공학Sw 아키텍처와 sw 공학
Sw 아키텍처와 sw 공학
 
[H3 2012] 오픈소스로 개발 실력 쌓기
[H3 2012] 오픈소스로 개발 실력 쌓기[H3 2012] 오픈소스로 개발 실력 쌓기
[H3 2012] 오픈소스로 개발 실력 쌓기
 
Framework Engineering 2.1
Framework Engineering 2.1Framework Engineering 2.1
Framework Engineering 2.1
 
스타트업 홍보의 이론과 실제 20130323
스타트업 홍보의 이론과 실제 20130323스타트업 홍보의 이론과 실제 20130323
스타트업 홍보의 이론과 실제 20130323
 
[NEXT] Android Profiler
[NEXT] Android Profiler[NEXT] Android Profiler
[NEXT] Android Profiler
 
아키텍트가 바라보는 Spring framework
아키텍트가 바라보는 Spring framework아키텍트가 바라보는 Spring framework
아키텍트가 바라보는 Spring framework
 
Google mail
Google mailGoogle mail
Google mail
 
세미나 Spring mybatis
세미나 Spring mybatis세미나 Spring mybatis
세미나 Spring mybatis
 
Docker at Deview 2013
Docker at Deview 2013Docker at Deview 2013
Docker at Deview 2013
 
김동건, 게임팅커가 되자, 2015년 데브캣 스튜디오 워크샵
김동건, 게임팅커가 되자, 2015년 데브캣 스튜디오 워크샵김동건, 게임팅커가 되자, 2015년 데브캣 스튜디오 워크샵
김동건, 게임팅커가 되자, 2015년 데브캣 스튜디오 워크샵
 
좋은 디자이너, 나쁜 프로젝트매니저, 이상한 개발자
좋은 디자이너, 나쁜 프로젝트매니저, 이상한 개발자좋은 디자이너, 나쁜 프로젝트매니저, 이상한 개발자
좋은 디자이너, 나쁜 프로젝트매니저, 이상한 개발자
 
5.yobi를 활용한 개발자 협업 및 배포 프로세스
5.yobi를 활용한 개발자 협업 및 배포 프로세스5.yobi를 활용한 개발자 협업 및 배포 프로세스
5.yobi를 활용한 개발자 협업 및 배포 프로세스
 
김충효, 10년째 같은 회사를 다니고 있습니다
김충효, 10년째 같은 회사를 다니고 있습니다김충효, 10년째 같은 회사를 다니고 있습니다
김충효, 10년째 같은 회사를 다니고 있습니다
 
HTML5를 활용한 하이브리드 앱개발하기
HTML5를 활용한 하이브리드 앱개발하기HTML5를 활용한 하이브리드 앱개발하기
HTML5를 활용한 하이브리드 앱개발하기
 
2.네이버 프론트엔드 김지태
2.네이버 프론트엔드 김지태2.네이버 프론트엔드 김지태
2.네이버 프론트엔드 김지태
 

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

꿀밋업시리즈3탄_Spring Boot를 활용한 마이크로서비스 개발과 페어프로그래밍(TDD)
꿀밋업시리즈3탄_Spring Boot를 활용한 마이크로서비스 개발과 페어프로그래밍(TDD)꿀밋업시리즈3탄_Spring Boot를 활용한 마이크로서비스 개발과 페어프로그래밍(TDD)
꿀밋업시리즈3탄_Spring Boot를 활용한 마이크로서비스 개발과 페어프로그래밍(TDD)
VMware Tanzu Korea
 
The art of readable code ch4 ch8
The art of readable code ch4   ch8The art of readable code ch4   ch8
The art of readable code ch4 ch8
Ki Sung Bae
 
깨끗한 코드 (클린 코드, Clean Code)
깨끗한 코드 (클린 코드, Clean Code)깨끗한 코드 (클린 코드, Clean Code)
깨끗한 코드 (클린 코드, Clean Code)
Jay Park
 
읽기 좋은 코드가 좋은코드다
읽기 좋은 코드가 좋은코드다읽기 좋은 코드가 좋은코드다
읽기 좋은 코드가 좋은코드다
wonmin lee
 
프로그래밍 패러다임의 진화 및 Spring의 금융권 적용
프로그래밍 패러다임의 진화 및 Spring의 금융권 적용프로그래밍 패러다임의 진화 및 Spring의 금융권 적용
프로그래밍 패러다임의 진화 및 Spring의 금융권 적용
중선 곽
 
NDC 2017 라이브 프로세스 분석을 통한 효율적인 게임 로직 개발 - 김성은
NDC 2017 라이브 프로세스 분석을 통한 효율적인 게임 로직 개발 - 김성은NDC 2017 라이브 프로세스 분석을 통한 효율적인 게임 로직 개발 - 김성은
NDC 2017 라이브 프로세스 분석을 통한 효율적인 게임 로직 개발 - 김성은
Sung Eun Kim
 
131 deview 2013 yobi-채수원
131 deview 2013 yobi-채수원131 deview 2013 yobi-채수원
131 deview 2013 yobi-채수원NAVER D2
 
시간 있으면 설계나 합시다
시간 있으면 설계나 합시다시간 있으면 설계나 합시다
시간 있으면 설계나 합시다codevania
 
Event Storming(이벤트 스토밍)
Event Storming(이벤트 스토밍)Event Storming(이벤트 스토밍)
Event Storming(이벤트 스토밍)
종일 김
 
dbt 101
dbt 101dbt 101
dbt 101
건 손
 
리팩토링
리팩토링리팩토링
리팩토링
Wonjun Hwang
 
Droid knights 2019 - (Large-scale App을 위한) Android Architecture 총정리
Droid knights 2019 - (Large-scale App을 위한) Android Architecture 총정리Droid knights 2019 - (Large-scale App을 위한) Android Architecture 총정리
Droid knights 2019 - (Large-scale App을 위한) Android Architecture 총정리
Sa-ryong Kang
 
Dev rookie codecomplete-1
Dev rookie codecomplete-1Dev rookie codecomplete-1
Dev rookie codecomplete-1
대영 노
 
Holub on-patterns-2-1
Holub on-patterns-2-1Holub on-patterns-2-1
Holub on-patterns-2-1정환 임
 
HolubOnPatterns/chapter2_1
HolubOnPatterns/chapter2_1HolubOnPatterns/chapter2_1
HolubOnPatterns/chapter2_1정환 임
 
[1B6]Realm a database for android & ios
[1B6]Realm a database for android & ios[1B6]Realm a database for android & ios
[1B6]Realm a database for android & ios
NAVER D2
 
11th.lecture.about. usability.2.20181130
11th.lecture.about. usability.2.2018113011th.lecture.about. usability.2.20181130
11th.lecture.about. usability.2.20181130
Jeongeun Kwon
 
애자일 프랙티스
애자일 프랙티스애자일 프랙티스
애자일 프랙티스
한 경만
 
프로그래밍 방식의 변천 과정
프로그래밍 방식의 변천 과정프로그래밍 방식의 변천 과정
프로그래밍 방식의 변천 과정
중선 곽
 
EMOCON 2015 - 품질과 테스트는 다르다
EMOCON 2015 - 품질과 테스트는 다르다EMOCON 2015 - 품질과 테스트는 다르다
EMOCON 2015 - 품질과 테스트는 다르다
이상한모임
 

Similar to 05. 아키텍트가 알아야할 12 97가지 (20)

꿀밋업시리즈3탄_Spring Boot를 활용한 마이크로서비스 개발과 페어프로그래밍(TDD)
꿀밋업시리즈3탄_Spring Boot를 활용한 마이크로서비스 개발과 페어프로그래밍(TDD)꿀밋업시리즈3탄_Spring Boot를 활용한 마이크로서비스 개발과 페어프로그래밍(TDD)
꿀밋업시리즈3탄_Spring Boot를 활용한 마이크로서비스 개발과 페어프로그래밍(TDD)
 
The art of readable code ch4 ch8
The art of readable code ch4   ch8The art of readable code ch4   ch8
The art of readable code ch4 ch8
 
깨끗한 코드 (클린 코드, Clean Code)
깨끗한 코드 (클린 코드, Clean Code)깨끗한 코드 (클린 코드, Clean Code)
깨끗한 코드 (클린 코드, Clean Code)
 
읽기 좋은 코드가 좋은코드다
읽기 좋은 코드가 좋은코드다읽기 좋은 코드가 좋은코드다
읽기 좋은 코드가 좋은코드다
 
프로그래밍 패러다임의 진화 및 Spring의 금융권 적용
프로그래밍 패러다임의 진화 및 Spring의 금융권 적용프로그래밍 패러다임의 진화 및 Spring의 금융권 적용
프로그래밍 패러다임의 진화 및 Spring의 금융권 적용
 
NDC 2017 라이브 프로세스 분석을 통한 효율적인 게임 로직 개발 - 김성은
NDC 2017 라이브 프로세스 분석을 통한 효율적인 게임 로직 개발 - 김성은NDC 2017 라이브 프로세스 분석을 통한 효율적인 게임 로직 개발 - 김성은
NDC 2017 라이브 프로세스 분석을 통한 효율적인 게임 로직 개발 - 김성은
 
131 deview 2013 yobi-채수원
131 deview 2013 yobi-채수원131 deview 2013 yobi-채수원
131 deview 2013 yobi-채수원
 
시간 있으면 설계나 합시다
시간 있으면 설계나 합시다시간 있으면 설계나 합시다
시간 있으면 설계나 합시다
 
Event Storming(이벤트 스토밍)
Event Storming(이벤트 스토밍)Event Storming(이벤트 스토밍)
Event Storming(이벤트 스토밍)
 
dbt 101
dbt 101dbt 101
dbt 101
 
리팩토링
리팩토링리팩토링
리팩토링
 
Droid knights 2019 - (Large-scale App을 위한) Android Architecture 총정리
Droid knights 2019 - (Large-scale App을 위한) Android Architecture 총정리Droid knights 2019 - (Large-scale App을 위한) Android Architecture 총정리
Droid knights 2019 - (Large-scale App을 위한) Android Architecture 총정리
 
Dev rookie codecomplete-1
Dev rookie codecomplete-1Dev rookie codecomplete-1
Dev rookie codecomplete-1
 
Holub on-patterns-2-1
Holub on-patterns-2-1Holub on-patterns-2-1
Holub on-patterns-2-1
 
HolubOnPatterns/chapter2_1
HolubOnPatterns/chapter2_1HolubOnPatterns/chapter2_1
HolubOnPatterns/chapter2_1
 
[1B6]Realm a database for android & ios
[1B6]Realm a database for android & ios[1B6]Realm a database for android & ios
[1B6]Realm a database for android & ios
 
11th.lecture.about. usability.2.20181130
11th.lecture.about. usability.2.2018113011th.lecture.about. usability.2.20181130
11th.lecture.about. usability.2.20181130
 
애자일 프랙티스
애자일 프랙티스애자일 프랙티스
애자일 프랙티스
 
프로그래밍 방식의 변천 과정
프로그래밍 방식의 변천 과정프로그래밍 방식의 변천 과정
프로그래밍 방식의 변천 과정
 
EMOCON 2015 - 품질과 테스트는 다르다
EMOCON 2015 - 품질과 테스트는 다르다EMOCON 2015 - 품질과 테스트는 다르다
EMOCON 2015 - 품질과 테스트는 다르다
 

More from YoungSu Son

Fault Tolerance 패턴
Fault Tolerance 패턴 Fault Tolerance 패턴
Fault Tolerance 패턴
YoungSu Son
 
Clean Code, Software Architecture, Performance Tuning
Clean Code, Software Architecture, Performance TuningClean Code, Software Architecture, Performance Tuning
Clean Code, Software Architecture, Performance Tuning
YoungSu Son
 
인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화
인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화
인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화
YoungSu Son
 
Prototype 패턴 (심만섭)
Prototype 패턴 (심만섭) Prototype 패턴 (심만섭)
Prototype 패턴 (심만섭)
YoungSu Son
 
Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)
Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)
Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)
YoungSu Son
 
Singleton 패턴 (김진영 - EVA, 소마에 10기)
Singleton 패턴 (김진영 -  EVA, 소마에 10기) Singleton 패턴 (김진영 -  EVA, 소마에 10기)
Singleton 패턴 (김진영 - EVA, 소마에 10기)
YoungSu Son
 
실전 서버 부하테스트 노하우
실전 서버 부하테스트 노하우 실전 서버 부하테스트 노하우
실전 서버 부하테스트 노하우
YoungSu Son
 
생성 패턴 (강태우 - 소마에 10기)
생성 패턴 (강태우 - 소마에 10기) 생성 패턴 (강태우 - 소마에 10기)
생성 패턴 (강태우 - 소마에 10기)
YoungSu Son
 
초보 개발자/학생들을 위한 오픈소스 트랜드
초보 개발자/학생들을 위한 오픈소스 트랜드 초보 개발자/학생들을 위한 오픈소스 트랜드
초보 개발자/학생들을 위한 오픈소스 트랜드
YoungSu Son
 
DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)
DevOps 오픈소스 트랜드 (클라우드, 모바일 중심) DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)
DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)
YoungSu Son
 
모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101)
모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101) 모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101)
모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101)
YoungSu Son
 
DevOps 시대가 요구하는 품질확보 방법
DevOps 시대가 요구하는 품질확보 방법 DevOps 시대가 요구하는 품질확보 방법
DevOps 시대가 요구하는 품질확보 방법
YoungSu Son
 
클라우드 환경에서 알아야할 성능 이야기
클라우드 환경에서 알아야할 성능 이야기클라우드 환경에서 알아야할 성능 이야기
클라우드 환경에서 알아야할 성능 이야기
YoungSu Son
 
Android 성능 지표와 Oreo 의 개선사항
Android 성능 지표와  Oreo 의 개선사항 Android 성능 지표와  Oreo 의 개선사항
Android 성능 지표와 Oreo 의 개선사항
YoungSu Son
 
안드로이드 Oreo의 변화와 모바일 앱/플랫폼의 적합한 성능 측정 방법
안드로이드 Oreo의 변화와  모바일 앱/플랫폼의 적합한 성능 측정 방법안드로이드 Oreo의 변화와  모바일 앱/플랫폼의 적합한 성능 측정 방법
안드로이드 Oreo의 변화와 모바일 앱/플랫폼의 적합한 성능 측정 방법
YoungSu Son
 
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
YoungSu Son
 
[NEXT] Android Profiler 사용법
[NEXT] Android Profiler 사용법 [NEXT] Android Profiler 사용법
[NEXT] Android Profiler 사용법
YoungSu Son
 
Android Studio 개발 셋팅 + Genymotion
Android Studio 개발 셋팅 + GenymotionAndroid Studio 개발 셋팅 + Genymotion
Android Studio 개발 셋팅 + Genymotion
YoungSu Son
 
FullStack 개발자 만들기 과정 소개 (Android + MEAN Stack + Redis 다루기)
FullStack 개발자 만들기 과정 소개  (Android + MEAN Stack + Redis 다루기) FullStack 개발자 만들기 과정 소개  (Android + MEAN Stack + Redis 다루기)
FullStack 개발자 만들기 과정 소개 (Android + MEAN Stack + Redis 다루기)
YoungSu Son
 
[NEXT] Flask 로 Restful API 서버 만들기
[NEXT] Flask 로 Restful API 서버 만들기 [NEXT] Flask 로 Restful API 서버 만들기
[NEXT] Flask 로 Restful API 서버 만들기
YoungSu Son
 

More from YoungSu Son (20)

Fault Tolerance 패턴
Fault Tolerance 패턴 Fault Tolerance 패턴
Fault Tolerance 패턴
 
Clean Code, Software Architecture, Performance Tuning
Clean Code, Software Architecture, Performance TuningClean Code, Software Architecture, Performance Tuning
Clean Code, Software Architecture, Performance Tuning
 
인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화
인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화
인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화
 
Prototype 패턴 (심만섭)
Prototype 패턴 (심만섭) Prototype 패턴 (심만섭)
Prototype 패턴 (심만섭)
 
Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)
Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)
Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)
 
Singleton 패턴 (김진영 - EVA, 소마에 10기)
Singleton 패턴 (김진영 -  EVA, 소마에 10기) Singleton 패턴 (김진영 -  EVA, 소마에 10기)
Singleton 패턴 (김진영 - EVA, 소마에 10기)
 
실전 서버 부하테스트 노하우
실전 서버 부하테스트 노하우 실전 서버 부하테스트 노하우
실전 서버 부하테스트 노하우
 
생성 패턴 (강태우 - 소마에 10기)
생성 패턴 (강태우 - 소마에 10기) 생성 패턴 (강태우 - 소마에 10기)
생성 패턴 (강태우 - 소마에 10기)
 
초보 개발자/학생들을 위한 오픈소스 트랜드
초보 개발자/학생들을 위한 오픈소스 트랜드 초보 개발자/학생들을 위한 오픈소스 트랜드
초보 개발자/학생들을 위한 오픈소스 트랜드
 
DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)
DevOps 오픈소스 트랜드 (클라우드, 모바일 중심) DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)
DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)
 
모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101)
모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101) 모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101)
모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101)
 
DevOps 시대가 요구하는 품질확보 방법
DevOps 시대가 요구하는 품질확보 방법 DevOps 시대가 요구하는 품질확보 방법
DevOps 시대가 요구하는 품질확보 방법
 
클라우드 환경에서 알아야할 성능 이야기
클라우드 환경에서 알아야할 성능 이야기클라우드 환경에서 알아야할 성능 이야기
클라우드 환경에서 알아야할 성능 이야기
 
Android 성능 지표와 Oreo 의 개선사항
Android 성능 지표와  Oreo 의 개선사항 Android 성능 지표와  Oreo 의 개선사항
Android 성능 지표와 Oreo 의 개선사항
 
안드로이드 Oreo의 변화와 모바일 앱/플랫폼의 적합한 성능 측정 방법
안드로이드 Oreo의 변화와  모바일 앱/플랫폼의 적합한 성능 측정 방법안드로이드 Oreo의 변화와  모바일 앱/플랫폼의 적합한 성능 측정 방법
안드로이드 Oreo의 변화와 모바일 앱/플랫폼의 적합한 성능 측정 방법
 
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
 
[NEXT] Android Profiler 사용법
[NEXT] Android Profiler 사용법 [NEXT] Android Profiler 사용법
[NEXT] Android Profiler 사용법
 
Android Studio 개발 셋팅 + Genymotion
Android Studio 개발 셋팅 + GenymotionAndroid Studio 개발 셋팅 + Genymotion
Android Studio 개발 셋팅 + Genymotion
 
FullStack 개발자 만들기 과정 소개 (Android + MEAN Stack + Redis 다루기)
FullStack 개발자 만들기 과정 소개  (Android + MEAN Stack + Redis 다루기) FullStack 개발자 만들기 과정 소개  (Android + MEAN Stack + Redis 다루기)
FullStack 개발자 만들기 과정 소개 (Android + MEAN Stack + Redis 다루기)
 
[NEXT] Flask 로 Restful API 서버 만들기
[NEXT] Flask 로 Restful API 서버 만들기 [NEXT] Flask 로 Restful API 서버 만들기
[NEXT] Flask 로 Restful API 서버 만들기
 

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

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