제 12회 한국 자바 개발자 컨퍼런스 : 3번째 Track, 1번째 컨퍼런스
아키텍트가 알아야할 12/97가지(손영수)
중요도 : 90점
이해도 : 90점
적용도 : 90점
프로젝트 성공을 위한 적절한 조언들이라 생각됨. 12회 자바 개발자 컨퍼런스중 TOP 3안에 들 정도로 좋은 내용들이라생각됨. 어느정도 프로젝트 매니징을 한다면 꼭 봐여할것으로 여겨짐. 프로젝트가 산으로 간 경험을 해봤다면 필독!!
꼭 Architect가 아니더라도 한번 볼것.
조언1 : Vasa호 이야기
--> 모든 요구사항을 충족시키려는 시도는 궁극적으로 아무것도 수행할 수 없는 불완전한 아키텍처를 만든다.
조언2 : 아키텍팅이란 균형에 관한것이다.
--> 요구사항들의 우선순위를 정하는것. 투표권을 1인당 3개만 줌. 그래서 중요도별 요구사항을 정리.
--> 단 QAW, ATAM은 구축하고자하는 시스템이 명확하고 이해당사자들이 이 시스템을 이해하고 있을때 적용가능하다. 이해 당사자들간의 정치관계를 조심해라 또한 투표권을 전체 팀원에 적절히 배분해라
조언3 : 요구사항이 명확하지 않을 때, 걸어 다니는 해골로 시작해라.
--> 해골 : 종단(예를 들면 UI~DB까지) 간을 오가며 수행되는 가벼운 구현체
--> 모든 종단을 다 관통하는 주요 시나리오를 몇개 만들어라
--> 시스템의 외적/내적인 요구사항을 자연스럽게 도출할 수 있다.
조언4 : 설계의 기준으로 불확실성을 사용해라
--> A와B중 하나를 결정하려고 시도하는 대신, 둘 사이의 결정이 덜 중요하게 만들기 위해 어떻게 설계해야할까 고민하라
조언5 : 높이 1000피트의 뷰를 가져라
--> 3만피트도 아닌 0피트도 아닌 적정한 높이의 관점을 가져야한다.
적절한 관점을 유지하기 위한 도구 xDepend (Ndepend, Xdepend, CDepend), STAN
NDepend : http://www.xdepend.com
STAN(Structure Analysis for Java) : http://stan4j.com/eclipse/eclipse-integration.html
: 이클립스에서 동작하는 프로젝트에 있는 클래스 분석 툴, 500개 클래스까지는 무료
: Instability가 높다 ==> 바꾸기 쉽다. (가져다 쓰는 놈들이 없으므로)
: Instability가 낮다 ==> 바꾸기 어렵다. (가져다 쓰는 놈들이 많으므로) ==> 인터페이스 추가 필요
--> 툴은 툴일뿐 좋은 가이드로만 생각하자. 개발자에게 Instability가 낮으니 얼마까지 맞추라는 등 너무 강요하면, 꼼수만 부리고 오히려 아키텍쳐가 무너진다.
조언6 : 구현 가능한 것만 설계해라
--> 신기술, 새로운 프레임워크 도입? 감언이설에 속지말자
--> 차세대 시스템 경험담 ==> 이래서 프리랜서들이 차세대는 지옥문이라 부르는가?
조언7 : 가장 큰 문제는 기술이 아니다.
--> 대화를 해라, 회의시 침묵하는 사람의 발언을 이끌어라
조언8 : 반복 작업과 싸워라
--> UML 툴인 EA 소개, 저렴 1copy당 20~30만원 사이
EA (Enterprise Architect) 장점
==> 강력한 코드 탬플릿 생성 기능
==>테스팅 생성 및 관리 (기존 Unit Testing과 연동됨)
==> 강력한 역공학 기능
==> 다양한 문서 포멧 제공
: 예전 프로젝트 할때 써봤는데.. 막판까지의 잦은 요구사항 변경으로 결국 포기한 아픈 기억이..
조언9 : 드워프, 엘프, 마법사 그리고 왕
--> 왕(아키텍트)는 모든 종족과 친해야 함. 모든 종족(이해 당사자)을 이끌어 같이 일할 수 있도록 도와야 한다.
--> 서로 보완적인 능력을 가진 팀 만들기
조언10 : 정경유착
--> 아키텍트의 정치 : 이해관계자 사이에서 정당성, 타당성을 바탕으로 이해관계를 조율하고 설득해야한다.
--> 아키텍트는 올바른 "정치"를 하기 위해 정경유착의 고리를 끊고, 특정 제품에 자유로울 필요가 있다.
조언11 : 고객의 고객.. 고객을 알아라
--> google powermeter 사업포기 : 스마트그리스 사업
--> oPower라는 조그마한 회사에게 밀림. 다윗과 골리앗의 싸움
--> oPower는 Paper를 이용한 고객 인터페이스가 있어서, 장년층, 노년층 고객을 흡수
--> 조그만 차이가 큰 결과로 나타난다.
조언12 : 컨설팅과 사과 이야기
--> 컨설턴트가 주는 사과는 독사과일수도 있고 맛있는 사과일수도 있다.
--> 컨설턴트는 이해 당사자들 모두를 이해하고 어떠한 benefit을 줄 수 있는지 설명해야한다.
--> 컨설팅 받는 사람은 무조건적인 저항보다는 컨설턴트가 더 도메인 전문가이니 협상을 해 나가야한다.
아키텍트가 알아야할 12/97가지(손영수) 발표자료 다운로드 :
SlideShare : 손영수님 블로그에서..
아키텍트가 알아야할 12/97가지(손영수)
중요도 : 90점
이해도 : 90점
적용도 : 90점
프로젝트 성공을 위한 적절한 조언들이라 생각됨. 12회 자바 개발자 컨퍼런스중 TOP 3안에 들 정도로 좋은 내용들이라생각됨. 어느정도 프로젝트 매니징을 한다면 꼭 봐여할것으로 여겨짐. 프로젝트가 산으로 간 경험을 해봤다면 필독!!
꼭 Architect가 아니더라도 한번 볼것.
조언1 : Vasa호 이야기
--> 모든 요구사항을 충족시키려는 시도는 궁극적으로 아무것도 수행할 수 없는 불완전한 아키텍처를 만든다.
조언2 : 아키텍팅이란 균형에 관한것이다.
--> 요구사항들의 우선순위를 정하는것. 투표권을 1인당 3개만 줌. 그래서 중요도별 요구사항을 정리.
--> 단 QAW, ATAM은 구축하고자하는 시스템이 명확하고 이해당사자들이 이 시스템을 이해하고 있을때 적용가능하다. 이해 당사자들간의 정치관계를 조심해라 또한 투표권을 전체 팀원에 적절히 배분해라
조언3 : 요구사항이 명확하지 않을 때, 걸어 다니는 해골로 시작해라.
--> 해골 : 종단(예를 들면 UI~DB까지) 간을 오가며 수행되는 가벼운 구현체
--> 모든 종단을 다 관통하는 주요 시나리오를 몇개 만들어라
--> 시스템의 외적/내적인 요구사항을 자연스럽게 도출할 수 있다.
조언4 : 설계의 기준으로 불확실성을 사용해라
--> A와B중 하나를 결정하려고 시도하는 대신, 둘 사이의 결정이 덜 중요하게 만들기 위해 어떻게 설계해야할까 고민하라
조언5 : 높이 1000피트의 뷰를 가져라
--> 3만피트도 아닌 0피트도 아닌 적정한 높이의 관점을 가져야한다.
적절한 관점을 유지하기 위한 도구 xDepend (Ndepend, Xdepend, CDepend), STAN
NDepend : http://www.xdepend.com
STAN(Structure Analysis for Java) : http://stan4j.com/eclipse/eclipse-integration.html
: 이클립스에서 동작하는 프로젝트에 있는 클래스 분석 툴, 500개 클래스까지는 무료
: Instability가 높다 ==> 바꾸기 쉽다. (가져다 쓰는 놈들이 없으므로)
: Instability가 낮다 ==> 바꾸기 어렵다. (가져다 쓰는 놈들이 많으므로) ==> 인터페이스 추가 필요
--> 툴은 툴일뿐 좋은 가이드로만 생각하자. 개발자에게 Instability가 낮으니 얼마까지 맞추라는 등 너무 강요하면, 꼼수만 부리고 오히려 아키텍쳐가 무너진다.
조언6 : 구현 가능한 것만 설계해라
--> 신기술, 새로운 프레임워크 도입? 감언이설에 속지말자
--> 차세대 시스템 경험담 ==> 이래서 프리랜서들이 차세대는 지옥문이라 부르는가?
조언7 : 가장 큰 문제는 기술이 아니다.
--> 대화를 해라, 회의시 침묵하는 사람의 발언을 이끌어라
조언8 : 반복 작업과 싸워라
--> UML 툴인 EA 소개, 저렴 1copy당 20~30만원 사이
EA (Enterprise Architect) 장점
==> 강력한 코드 탬플릿 생성 기능
==>테스팅 생성 및 관리 (기존 Unit Testing과 연동됨)
==> 강력한 역공학 기능
==> 다양한 문서 포멧 제공
: 예전 프로젝트 할때 써봤는데.. 막판까지의 잦은 요구사항 변경으로 결국 포기한 아픈 기억이..
조언9 : 드워프, 엘프, 마법사 그리고 왕
--> 왕(아키텍트)는 모든 종족과 친해야 함. 모든 종족(이해 당사자)을 이끌어 같이 일할 수 있도록 도와야 한다.
--> 서로 보완적인 능력을 가진 팀 만들기
조언10 : 정경유착
--> 아키텍트의 정치 : 이해관계자 사이에서 정당성, 타당성을 바탕으로 이해관계를 조율하고 설득해야한다.
--> 아키텍트는 올바른 "정치"를 하기 위해 정경유착의 고리를 끊고, 특정 제품에 자유로울 필요가 있다.
조언11 : 고객의 고객.. 고객을 알아라
--> google powermeter 사업포기 : 스마트그리스 사업
--> oPower라는 조그마한 회사에게 밀림. 다윗과 골리앗의 싸움
--> oPower는 Paper를 이용한 고객 인터페이스가 있어서, 장년층, 노년층 고객을 흡수
--> 조그만 차이가 큰 결과로 나타난다.
조언12 : 컨설팅과 사과 이야기
--> 컨설턴트가 주는 사과는 독사과일수도 있고 맛있는 사과일수도 있다.
--> 컨설턴트는 이해 당사자들 모두를 이해하고 어떠한 benefit을 줄 수 있는지 설명해야한다.
--> 컨설팅 받는 사람은 무조건적인 저항보다는 컨설턴트가 더 도메인 전문가이니 협상을 해 나가야한다.
아키텍트가 알아야할 12/97가지(손영수) 발표자료 다운로드 :
SlideShare : 손영수님 블로그에서..
05. 아키텍트가 알아야할 12 97가지
View more PowerPoint from YoungSu Son
'자바 일반' 카테고리의 다른 글
java5에 추가된 foreach문 (0) | 2012.03.22 |
---|---|
JCO 12회, 성공하는 개발자를 위한 아키텍처 요구사항 분석 방법(강승준) (0) | 2012.02.27 |
JCO 12회 프로그램목록 및 기조연설 (0) | 2012.02.22 |
자바 서버에서 현재 시간 구하기 (0) | 2012.02.17 |
java 숫자를 문자로 변환, 문자를 숫자로 변환 방법 (0) | 2011.12.09 |