NIKON CORPORATION | NIKON D80 | 2011:06:19 15:13:57


• 부제 : Architecting, Designing, and Developing Reusable Libraries
• 발표자 : 손영수(http://www.arload.net)
∘ EVA팀 리더
∘ PLoP 패턴 저자
∘ AsianPLoP

• 개발자의 진화
• 건강을 지켜라.
• 정덕영 : http://uvicrabbit.tistory.com
• Framework : semi-product <-> libraries 와는 다르다.
∘ 애플리케이션의 제어는 Framework 에게 넘기지.
∘ Framework 를 사용하면서, Framework에 대한 공부학습요구량은 증가하였지만, 실제로 작성하는 소스는 줄어들었다.
∘ Control Flow(IoC) 권한을 가지고 있는 녀석이 누구냐?
∘ 사용 이유
‣ 중복 제거(Avoid Dulpication)
‣ 생산성 향상
‣ 표준성 싸움(DeFacto war)

NIKON CORPORATION | NIKON D80 | 2011:06:19 15:04:29


• 5topic
∘ Organization(조직) - The most powerful design tool
‣ 기술의 끝장(대부분의 문제는 사람에게서 발생한다)
‣ 많이 먹이면 관계가 원활해진다.
‣ Project management Triangle
‣ +1 Organization (조직의 문화를 고려하라).
• conway's law(http://en.wikipedia.org/wiki/Conway's_Law) : 4개의 그룹이 일을 하게되면, 4종류의 컴파일을 얻게 된다?
‣ 분위기 : 가족적인가?
‣ peremptory
‣ 조직의 크기
• 작은 조직
∘ simple Design
∘ Consistency Design : 분할되어 있는 디자인
∘ 80/20 법칙에 집중
• 큰 조직
∘ powerful design
∘ lack Consistency
‣ Framework를 사용하는 조직에게 맞춰라.
• 요구사항을 줄이는 방법
∘ 밥을 사라
∘ 호형호제
∘ Planning
‣ Peanut Butter
‣ Skyscrapers
‣ Moderation(중도)
• MS : MileStone = Scenarios + Feature
∘ Architecture
‣ Type 고려
• Primitives
• Libraries
• Abstractions
• Manage Dependencies
∘ Component : 시대의 흐름에 따라서 결합형태(기능이나 모양)이 변하는 것(가치를 흡수)
∘ Type of Dependencies
‣ API Dependency
‣ Implementation Dependency
‣ Circular Dependency : A -> B -> C -> A -> B -> C
∘ Layer를 적절하게 나누는 작업이 필요하다.
∘ 엄격한 계층화
∘ Tools를 이용하여 Dependency가 커지는 것을 제한한다.
∘ xDepend(Ndepend, Xdepend, CDepend)
∘ Solution : creat new a package.
‣ Packaging Principle
• Package Cohesion Principle
• Pakcage Coupling Principle
‣ 호환성 (Compatibility)
• 팀의 공간
• 소스를 보여주고 말하기
• 문제 처리 공간
• 물어볼 사람이 있다.
∘ Design
‣ Code Samples
‣ KISS(Keep It Simple! Stupid!
‣ 우선순위를 중심으로 해서 구현하기
∘ Development


• 조직에 대해서 신경써라.
• 아... 내가 산 아키텍트가 알아야할 97가지 이야기...를 쓴 사람이구나....
소프트웨어아키텍트가알아야할97가지
카테고리 미분류
지은이 RICHARD MONSON HAEFEL (지앤선, 2011년)
상세보기
• 발표는 재미있게 하는데, 두번째 들으니까... 식상하네...
  작년 아키텍트 대회에서 들었던 내용과 크게 다르지 않은 내용이었다. 처음 들었을 때는 신선하고 재미있었지만, 두번째 들으니 조금 시큰둥하게 느껴졌다. 처음 들었을 때도 그랬지만, 두번째 에서도 발표시간을 제대로 지키지 못하는 모습을 보니 준비가 무성의하지 않았는가 하는 생각도 들었다.
  분명 발표를 준비하느라 노력을 기울이셨을테지만, 사소한 것들에서 점수가 깍이는 것이 많이 아쉬웠다.

  1. Favicon of http://www.arload.net BlogIcon 손영수 2011.06.22 15:11 신고

    안녕하세요 손영수입니다.
    마음이 아프네요.. T_T 여튼 피드백 달게 받겠습니다.
    감사합니다.

    • 헙.... 죄... 죄송합니다.

      힘들게 준비하셨을텐데, 가볍게 가서는 험담으로 마무리한건
      아닌지...

      다음에는 좀 더 멋진 발표를 기대하겠습니다.
      변덕스런 날씨, 건강 유의하세요!

출처 : http://en.wikipedia.org/wiki/Software_architect

Types of software architects

The enterprise architect handles business-related software decisions that frequently can involve multiple software systems within an organization, spanning several projects teams, and often at more than one site. The Enterprise Architect may seldom see or interact with source code.

An application architect works with a single software application. This may be a full- or a part-time role. The application architect is almost always an active software developer.

Other similar titles in use, but without consensus on their exact meaning, include:

The table below indicates many of the differences between various kinds of software architects:

Architect TypeStrategic ThinkingSystem InteractionsCommunicationDesign
Enterprise Architect Across Projects Highly Abstracted Across Organization Minimal, High Level
Solutions Architect Focused on solution Very Detailed Multiple Teams Detailed
Application Architect Component re-use, maintainability Centered on single Application Single Project Very Detailed

In the software industry, as the table above suggests, the various versions of architect do not always have the same goals.[1]



Architect(아키텍트)에도 여러종류가 있구나. 나에게 어울리는 타입은 뭘까?
중간적인 위치라고 볼 수 있는 Solution Architect가 어울리는 것 같다.
목표는 Enterprise Architect로 해야겠다.

'Programming' 카테고리의 다른 글

에디터에 대해서  (0) 2011.03.09
OpenSource Project 를 할만한 게 뭐가 있을까?  (0) 2011.01.28
Types of software architects  (0) 2011.01.01
What dows 'PMD' mean?  (0) 2010.12.31
[Velocity] velocity.properties  (0) 2010.03.13
Velocity 설정법  (0) 2010.02.21

+ Recent posts