Architecture Refactoring with NOO [JCO version]
Upcoming SlideShare
Loading in...5
×
 

Architecture Refactoring with NOO [JCO version]

on

  • 1,030 views

Architecture Visualization & NOO를 통한 올바른 Architecture Refactoring의 기준을 설명 합니다.

Architecture Visualization & NOO를 통한 올바른 Architecture Refactoring의 기준을 설명 합니다.

Statistics

Views

Total Views
1,030
Views on SlideShare
1,027
Embed Views
3

Actions

Likes
9
Downloads
36
Comments
0

2 Embeds 3

http://www.slideee.com 2
http://nigayo.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Architecture Refactoring with NOO [JCO version] Architecture Refactoring with NOO [JCO version] Presentation Transcript

    • Architecture  Refactoring   (Nature  of  Order)  
    • Youngsu Son indigoguru@gmail.com NHN NEXT Professor EVA Member UrQA Committer NEAOSS WG2 Leader Hillside Group Member AsianPLoP Co-Chair
    • Thanks  to..  
    • 나눌 이야기들..   •  Architecture  Visualiza<on   •  Nature  of  Order  
    • 
    •   
    •   **
    •   Architecture
    •   Visualization
    •   
    • 소프트웨어
    •   역시
    •   
    •   시각적으로
    •   
    •    의미있는
    •   내부를
    •   볼수
    •   보인다면..
    •   
    • 하늘에서
    •   볼까?
    •   
    •    (30000
    •   feet)
    •   
    • 
    •   뭐가
    •   보이시나요??
    •   
    • 자세히
    •   (0
    •   feet)
    •   볼까?
    •   
    • 제한된
    •   코드로
    •    프로젝트가
    •   
    •    잘되고
    •   있는지
    •    판단은?
    •   
    • Diagram
    •   vs.
    •   Code
    •    Diagram  (3만 피트) •  다이어그램의 Line의 의미는? •  의존성? •  데이터 흐름? •  버스와 같은 공유자원? Code  (0  피트) •  너무 상세한 정보임. •  전체적인 구조를 보지 못함.
    • 해결책은..
    •    적절한
    •   
    •   1000
    •   피트의
    •   뷰
    •   
    • 지표..
    •   
    • 지표별
    •   커버리지
    •    속성
    •    지표
    •    P
    •   
    •    C
    •    M
    •    Size
    •    Line
    •   of
    •   Code
    •    O
    •    O
    •    O
    •    Instability
    •   /
    •   Abstractness
    •    O
    •    Cohesion
    •    Lack
    •   of
    •   Cohesion
    •   of
    •   Method
    •    O
    •    DSM
    •    O
    •    O
    •    O
    •    Relation
    •   Chart
    •    Dependency
    •    O
    •    O
    •    O
    •    Tangled
    •    O
    •    Component
    •   Dependency,
    •   CCD,
    •   ACD
    •    O
    •    Depth
    •   of
    •   Inheritance
    •   Tree
    •    Response
    •    O
    •    Number
    •   Of
    •   Children
    •   in
    •   Tree
    •    Branch
    •   
    •    F
    •    O
    •    Cyclomatic
    •   Complexity
    •    O
    •    Weight
    •   Method
    •   for
    •   Class
    •    O
    •    Response
    •   For
    •   a
    •   Class
    •    O
    •   
    • 지표 1     Instability/Abstractness  Graph
    • Instability
    •    • 패키지의
    •   움직일
    •   수
    •   있는
    •   여력을
    •   판단하는
    •   지표
    •    • 다른
    •   패키지에
    •   영향을
    •   미치지
    •   않고,
    •   
    •    
    •   해당
    •   패키지를
    •   쉽게
    •   변경
    •   할
    •   수
    •   있는가?
    •    • Instability
    •   I
    •   =
    •   Ce
    •   /
    •   (Ca+Ce)
    •    • Ce
    •   =
    •   Efferent
    •   Coupling
    •   (Ingoing
    •   Dependencies)
    •    • Ca
    •   =
    •   Afferent
    •   Coupling
    •   (Outgoing
    •   Dependencies
    •   )
    •   
    • Instability
    •    를
    •   
    •    
    •    키지 다면 의
    •   패 고
    •   있 당신 이
    •   쓰 다.
    •    많 가
    •    지
    •   않 군 누 기
    •   쉽 꾸 I
    •   =
    •   
    •   Ce
    •   /
    •   (Ca+Ce)
    •    바 Instability
    •    
    •    당신의
    •   패키지가
    •   다른
    •   사람이
    •   많이
    •   쓴다면,
    •   
    •    즉
    •   Outgoing,
    •   Ca가
    •   많다면,
    •   
    •   
    •   여러분의
    •   패키지는
    •   변경하기
    •   어렵다.
    •   
    •    
    •    반대로
    •   Outgoing하는
    •   Ca가
    •   적고,
    •   Ingoing(다른
    •   패키지만
    •   사용만
    •   하는)
    •   
    •   Ce,
    •    여러분의
    •   패키지는
    •   쉽게
    •   변경해도
    •   된다.
    •    
    •    즉
    •   
    •   0.0에서
    •   0.3이면
    •   안정적인
    •   버전,
    •   
    •   0.7에서
    •   1.0이면
    •   불안정적인
    •   상태다
    •   
    •    
    •   
    •   
    • Abstractness
    •    Interface(Abstract)
    •   와
    •   Concrete
    •   Class를
    •   비교
    •    
    •    
    •   A
    •   =
    •   (#abstract
    •   classes
    •   /
    •   total
    •   #
    •   of
    •   classes)
    •    • Abstract
    •   class
    •   =
    •   interface,
    •   abstract다
    •   포함
    •    • Total
    •   #
    •   class
    •   
    •   =
    •   abstract
    •   class
    •   +
    •   concrete
    •   class
    •    • 0
    •   이면
    •   concrete
    •   class만
    •   있다.
    •   
    •    • 1
    •   이면
    •   abstract
    •   class만
    •   있다.
    •   
    •   
    • 다시
    •   보는
    •   그래프
    •    다른데서
    •   많이
    •   쓰는
    •    녀석이니
    •   조금
    •   더
    •    abstract를
    •   높여야
    •    돼!
    •   
    • 지표
    •   2
    •   
    •   
    •    DSM
    •   과
    •   Relation
    •   Chart
    •   
    •   
    • 간단한
    •   DSM
    •   
    • 잘
    •   계층화된
    •   DSM
    •   
    • 엄격한
    •   계층화를
    •   유지한
    •   
    •    시스템의
    •   DSM
    •   
    • 불완전한
    •   계층구조를
    •   가진
    •   시스템
    •   
    • 지표
    •   3
    •   
    •   
    •    Size
    •   of
    •   Component
    •   (LOC)
    •   
    • 지표
    •   4
    •   
    •   
    •    Cyclomatic
    •   Complexity
    •   
    • 지표 5.  WMC(Weighted  Method  per  Class)   WMC  =  ∑Cycloma<c  complexity  
    • 지표
    •   6
    •   
    •   -
    •   Tangled
    •    상위
    •   레이어의
    •   변화가
    •    하위
    •   레이어에도
    •   
    •    영향을
    •   미칠
    •   위험
    •   
    • Tangled
    •   란?
    •    역참조 갯수   전체 참조 갯수   * 100(%) 4  /  16 * 100(%)  =  25%  
    • 
    •   역
    •   참조없이
    •   레이어가
    •   잘
    •   나눠진
    •   아키텍쳐
    •    Tangled지표는   0에 가까울수록 좋다.   Frontend Communicator Framework
    • 지표
    •   7
    •   
    •   -
    •   CD
    •   ,
    •   CCD,
    •   ACD
    •    3 2 1 0 CD(Component
    •   dependency)
    •    
    •   =
    •   컴포넌트에
    •   영향을
    •   주는
    •   다른
    •   컴포넌트의
    •   갯수
    •   
    • CCD(Cumulated  Component  Dependency)  =  ∑CD   5   5   5   CCD
    •   =
    •   9
    •    5   5   5   Maximum
    •   CCD
    •   =
    •   5
    •   *
    •   6
    •   =
    •   30
    •   
    • Average  CD  =  CCD  /  Maximum  CCD  *  100(%)   ACD  =  9  /  30  *  100(%)  =  30%   5   5   5   CCD
    •   =
    •   9
    •    5   5   5   Maximum
    •   CCD
    •   =
    •   5
    •   *
    •   6
    •   =
    •   30
    •   
    • ACD(Average
    •   Component
    •   Dependency)
    •   지표
    •    
    •   Empty
    •   :
    •   만약
    •   노드간에
    •   참조가
    •   없다면
    •   ACD는
    •   0%이다.
    •    
    •    
    •   Chain
    •   :
    •   만약
    •   모든
    •   노드가
    •   하나의
    •   패스를
    •   형성하면
    •   ACD는
    •   50%이다.
    •    
    •    
    •   Cycle
    •   :
    •   만약
    •   모든노드가
    •   하나의
    •   순환을
    •   형성하면
    •   ACD는
    •   100%이다.
    •    Empty   Chain   Cycle  
    • 지표
    •   7
    •   -
    •   LCOM(Lack
    •   of
    •   Cohesion
    •   in
    •   Methods)
    •    
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   응집력부족
    •   지표
    •    클래스의
    •   응집력을
    •   판단하는
    •   지표
    •   
    • M1  =  생성자   M2  =  getFullAddress3   M3  =  getFullAddress   M4  =  getFullAddress1     M1이 접근 가능한 필드     M2이 접근 가능한 필드   M3이 접근 가능한 필드   M4이 접근 가능한 필드   {I1}  =  {∅}   {I2}  =  {aaa}   {I3}  =  {street,  city,  zipCode}   {I4}  =  {zipCode}    
    • 공집합의
    •   갯수
    •   |
    •   P
    •   |
    •    공집합이
    •   아닌
    •   갯수
    •   |
    •   Q
    •   |
    •   
    •    (I1∩I2)
    •   =
    •   {∅}
    •   
    •    (I1∩I3)
    •   =
    •   {∅}
    •    (I1∩I4)
    •   =
    •   {∅}
    •    (I2∩I3)
    •   =
    •   {∅}
    •    (I2∩I4)
    •   =
    •   {∅}
    •    (I3∩I4)
    •   =
    •   {zipCode}
    •    LCOM  =  |P|  -­‐  |Q|  =  4  
    • LCOM값이
    •   작으면:
    •    
    •    참조하는
    •   공통
    •   Field가
    •   많음
    •    응집력이
    •   있음
    •    LCOM값이
    •   크면:
    •    응집력이
    •   낮음
    •    하나의
    •   클래스를
    •   2개의
    •   클래스로
    •   
    •    나누는것이
    •   바람직함
    •   
    • 지표
    •   8.
    •   DIT(Depth
    •   of
    •   Inheritance
    •   Tree)
    •    2 1 0 DIT
    •   0은
    •   Root
    •   Class
    •    
    •    DIT
    •   크면
    •    
    •   -
    •   Class의
    •   행동
    •   예측
    •   어려움
    •    
    •   -
    •   시스템
    •   이해가
    •   어려움
    •    
    •    적절한
    •   DIT
    •    
    •   -
    •   객체지향
    •   언어에서
    •   재사용성을
    •   높임
    •    
    •   
    • 지표
    •   9.
    •   NOC
    •    (Number
    •   of
    •   Children
    •   in
    •   Tree)
    •    0 1 0 2 상속한
    •   클래스의
    •   갯수
    •    
    •    NOC가
    •   클수록
    •    
    •   -
    •   클래스
    •   변경
    •   시
    •   주의하여야
    •   함
    •   
    • 지표
    •   10.
    •   RFC(Response
    •   For
    •   a
    •   Class)
    •    클래스와
    •   연관된
    •   생성자,
    •   메소드의
    •   갯수
    •   
    •    classA와
    •   연관된
    •   메소드,
    •   생성자:
    •    
    •    classA()
    •    classA.callB()
    •    classB()
    •    classB.function()
    •    
    •    RFC
    •   =
    •   4
    •   
    • 어디서
    •   많이
    •   본
    •   MECE..
    •   
    • 지표별
    •   커버리지
    •    속성
    •    지표
    •    P
    •   
    •    C
    •    M
    •    Size
    •    Line
    •   of
    •   Code
    •    O
    •    O
    •    O
    •    Instability
    •   /
    •   Abstractness
    •    O
    •    Cohesion
    •    Lack
    •   of
    •   Cohesion
    •   of
    •   Method
    •    O
    •    DSM
    •    O
    •    O
    •    O
    •    Relation
    •   Chart
    •    Dependency
    •    O
    •    O
    •    O
    •    Tangled
    •    O
    •    Component
    •   Dependency,
    •   CCD,
    •   ACD
    •    O
    •    Depth
    •   of
    •   Inheritance
    •   Tree
    •    Response
    •    O
    •    Number
    •   Of
    •   Children
    •   in
    •   Tree
    •    Branch
    •   
    •    F
    •    O
    •    Cyclomatic
    •   Complexity
    •    O
    •    Weight
    •   Method
    •   for
    •   Class
    •    O
    •    Response
    •   For
    •   a
    •   Class
    •    O
    •   
    • 수
    •   많은
    •   시각화
    •   툴들..
    •    Free
    •    Java
    •    C++
    •    Commercial
    •   
    • 왜 안쓰나요?? •  대기업
    •   (제조업
    •   ,SI)-
    •   아키텍트
    •   팀
    •    •  중소기업­–
    •   운영,
    •   
    •    
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   개발자,
    •   
    •    
    •    
    •   
    •   
    •   
    •   
    •    
    •   
    •   
    •   
    •   PM
    •    •  NIPA
    •   ­–
    •   중소기업
    •   소프트웨어
    •   컨설팅
    •   지원
    •   
    • 이해하기
    •   어려운
    •   차트&지표들이
    •   존재하고
    •   
    •    무엇이
    •   문제가
    •   되는지
    •   한눈에
    •   알기
    •   힘들다
    •    
    •    어떻게
    •   개선을
    •   해야
    •   하는지도
    •   모르겠다!
    •   
    • **
    •   Nature
    •   of
    •   Order
    •   
    • 패턴의
    •   아버지
    •    Christopher
    •   Alexander
    •   
    • Published
    •   in
    •   1977
    •    
    •    3
    •   Authors
    •    
    •    3
    •   Assistants
    •    
    •    253
    •   Patterns
    •    
    •    1171
    •   Pages
    •    
    •    Written
    •   Over
    •   8
    •   Years
    •   
    • 이미
    •   구축된
    •   환경에
    •   있는
    •    패턴을
    •   이야기
    •   함
    •    건축,
    •   사람들의
    •   사회적
    •    연결에
    •   초점이
    •   맞추어져
    •    있다.
    •   
    • Self-Consciousness
    •   (자의식이
    •   강한)
    •   
    • 이질적인가??
    •   
    •   
    • 만약
    •   
    •    인디언이
    •   
    •    초가집을
    •   본다면..
    •    
    •    
    •    자연스러울까?
    •   
    • 자연에서
    •   답을
    •   찾자!
    •   
    • 2007년
    •   그
    •   해답을
    •   가져오다
    •   
    • 질서의
    •   본질
    •   
    •    (자연의
    •   설계,
    •   절차를
    •   배우다)
    •    The fifteen properties of things that have life Unfolding processes for creating “lively” things
    • 생명체가
    •   가지는
    •   15가지
    •   속성
    •   
    • Levels  of  Scale   Strong  Centers   Good  Shape   Local  Symmetries   Roughness   Echoes   Boundaries   Deep  Interlock   Ambiguity   The  Void   Alterna<ng   Repe<<on   Contrast   Simplicity     Inner  Calm   Posi<ve  Space   Gradients   Not-­‐Separateness  
    • 크기의 단계   좋은 모양   기계적이지 않은   (다듬어지지 않은)   강한 구심점   내부 대칭   되풀이   경계   깊은 연계   다양한 성질   여백   교차적을 일어나는 반복   대조   간결함 내부적인 고요함   양의 공간   점진적인 변화   나뉘어지지 않는  
    • 3.  Good  Shape   4.  Levels  of  Scale   1.  Posi<ve     Space   2.  Roughness   5.  Not-­‐Separateness   6.  Strong     Centers   7.Boundaries   8.  Contrast   9.  Void   11.  Simplicity     Inner  Calm   10.  Deep  Interlock   Ambiguity   10.  Echoes   10.  Alterna<ng  Repe<<on   10.  Local  Symmetries   10.  Gradients  
    • *
    •   Positive
    •   Space
    •   
    • Subject
    •    Positive
    •   
    •    Space
    •   
    •    Negative
    •    Space
    •   
    •   
    • 시스템을
    •   구성하는
    •   
    •    각각의
    •   요소들(elements)은
    •   
    •    
    •    하나의
    •   목적을
    •   구성하기
    •   위해
    •   완전하고,
    •   
    •    잘
    •   정의되어있어야
    •   한다.
    •   
    •    
    •    또
    •   다른
    •   이름..
    •   
    •   응집력..
    •    
    •   
    • 3~7세
    •   어린이
    •   신발
    •   살때
    •   기준은?
    •    귀여운
    •   
    •    기능성
    •   
    • Pain
    •   Point
    •   
    • 고객의
    •   
    •   문제를
    •   해결하자!
    •    =
    •    
    •   우리
    •   소프트에어의
    •   핵심가치
    •   
    • 비즈니스
    •   모델
    •   캔버스는
    •   창업자들이
    •   생각한
    •   가설이고,
    •    고객
    •   개발은
    •   창업자들이
    •   생각해낸
    •   해결책을
    •   검증하기
    •   보다는
    •   
    •    창업자들이
    •   가정한
    •   문제가
    •   진짜
    •   고객의
    •   문제인지
    •   검증하는
    •    것이다!
    •    
    •    
    •    Steve
    •   Blank
    •    
    •    Lean
    •   Startup의
    •   아버지
    •    Customer
    •   Development
    •   Method
    •   저자
    •   
    • 2013년
    •   Play
    •   마켓
    •   앱
    •   개수
    •   
    •    전체
    •   앱
    •   중
    •   Bug
    •   report를
    •   사용하는
    •   앱
    •    Bugsense
    •    7%
    •    ACRA
    •    3%
    •    Others
    •    0%
    •    not
    •   use
    •    90%
    •    새로운
    •   앱
    •   중
    •   Bug
    •   report를
    •   사용하는
    •   앱
    •    BugSense
    •    14%
    •    not
    •   use
    •    81%
    •    버그리포트
    •   시장
    •   점유율
    •    ACRA
    •    3%
    •    ACRA
    •    16%
    •    Others
    •    2%
    •    BugSense
    •    77%
    •    Crittercism
    •    5%
    •    Others
    •    2%
    •   
    • 왜
    •   안쓰지?
    •   불편한가?
    •   
    • Customer
    •   
    •    Validation
    •    고객의
    •    요구사항
    •    Feedback
    •    Customer
    •   
    •    Discovery
    •   
    • 기존
    •   경쟁
    •   제품의
    •   한계...
    •    사용자가
    •   앱을
    •   어떻게
    •    사용하다
    •   버그가
    •   발생
    •   
    •    하였는지
    •   알
    •   수
    •   가
    •   없어서
    •   
    •    버그
    •    재현에
    •    많은
    •    시간이
    •    걸렸다.
    •    
    •   Sleep
    •   If
    •   U
    •   Can
    •   개발자
    •    신재명
    •   BugSense사용
    •   중
    •   
    • 기존
    •   경쟁
    •   제품의
    •   한계...
    •    
    •   진정
    •   시급한
    •   버그가
    •   무엇인지
    •   
    •    
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   알
    •   수가
    •   없다.
    •   
    •    
    •    
    •    알람에서
    •    가장시급한
    •    버그는
    •    알람
    •    기능에서
    •    발생한
    •    버그이다.
    •    하지만
    •    버그의
    •    발생
    •    수에
    •    가려
    •    진짜
    •    시급한
    •    버그를
    •   노치게
    •   된다.
    •    말랑스튜디오
    •   CEO
    •    김영호
    •    BugSense사용
    •   중
    •   
    • Customer
    •   
    •    Validation
    •    Feedback
    •    고객의
    •    요구사항
    •    버그의
    •   위험
    •   정도를 
    •   판별
    •   할
    •   QA의
    •   부재
    •    Customer
    •   
    •    Discovery
    •    QA
    •   Insight
    •    가치찾기
    •   워크샵
    •   
    • QA
    •   Insight
    •    삼성전자
    •   소프트웨어QA
    •    조현길
    •   책임
    •   
    • QA
    •   Insight
    •    -
    •   QA는
    •   소프트웨어의
    •   품질을
    •   향상시키는
    •   역할
    •    
    •    -
    •   버그가
    •   발생하게되면
    •   이슈트레커를
    •   통해
    •   개발자에게
    •   버그에
    •   대한
    •   정보
    •   보고
    •    
    •    -
    •   버그가
    •   발생했을
    •   때
    •   양보다
    •   질을
    •   우선
    •   시
    •   하기
    •   위해
    •   위험도에
    •   따라
    •   등급을
    •    
    •   
    •   Crash,
    •   Critical,
    •   Major,
    •   Minor로
    •   분류
    •    
    •    -
    •   버그를
    •   재현시키는데
    •   가장
    •   많은
    •   시간을
    •   들임.
    •   
    •    
    •   
    •   재현이
    •   되지
    •   않는
    •   버그는
    •   버그로
    •   보지
    •   않음
    •    
    •    -
    •   New
    •   ->
    •   Assign
    •   ->
    •   Acknowledge
    •   ->
    •   Resolve
    •   ->
    •   Feedback
    •   과정으로
    •   버그를
    •   관리하 며
    •   대화형식으로
    •   기록을
    •   남겨둔다.
    •    
    •    -
    •   소프트웨어
    •   평가지표를
    •   도출한다.
    •    
    •    -
    •   QA는
    •   소프트웨어개발
    •   프로세스
    •   전반에
    •   관여하게
    •   된다.
    •   
    • 핵심
    •   가치
    •   찾기
    •   워크샵
    •   진행
    •   
    • 1)
    •   Purpose
    •   &
    •   Goal
    •   수립
    •   
    • 2)
    •   Why
    •   &
    •   Why
    •   not
    •   Buy?
    •   
    • 사야
    •   되는
    •   이유와
    •   사지
    •   않는
    •   이유를
    •   
    •    각자
    •   30개씩
    •   적고
    •   그룹화
    •   한다
    •   
    • 3)
    •   Simple
    •   Value
    •   Proposition
    •   
    • 4)
    •   User
    •   Profiling을
    •   통한
    •   Opportunity도출
    •   
    • 작성한
    •   페르소나
    •   중
    •   
    •    우선순위가
    •   높은
    •   페르소나를
    •   선택하고
    •    키워드를
    •   그룹화
    •   
    • 5)
    •   Convergence
    •   
    • UrQA는
    •   모바일
    •   앱
    •   개발팀에게
    •   
    •    VALUE
    •    크래시를
    •   빠르게
    •   대응
    •    Person-hour
    •   절약
    •    차별화된
    •   기술력
    •    가치를
    •   제공하는데
    •    FEATURE
    •    실시간으로
    •   에러를
    •   
    •    등급화하여
    •   리포팅
    •    사용자
    •   이벤트
    •   경로
    •    시각화
    •    C/C++
    •   네이티브
    •   
    •    크래시
    •   리포트
    •   제공 를
    •   통해서
    •   이루어
    •   진다.
    •   
    • 판단
    •   기준
    •   즉
    •   목적성이
    •   정립됨
    •   
    • 그래서
    •   나온
    •   소프트웨어
    •   
    • 아이콘과
    •   색을
    •   
    •    이용한
    •   버그의
    •   등급
    •   ,
    •   갯수표시
    •   
    • Event
    •   Path
    •    버그를
    •   발생시킨
    •   사용자
    •   경로를
    •   
    •    시각화해서
    •   보여줌
    •    CRASH
    •   
    • OS버전
    •    App
    •   버전
    •   대비
    •   OS버전의
    •   
    •    버그
    •   발생량을
    •   보여줌
    •    앱
    •   버전
    •   
    • 다양한 통계자료를 기간 별로   한눈에 파악 가능  
    • Bugsense,
    •   Acra
    •   
    •   
    • UrQA
    •   
    • Positive
    •   Space
    •   지표
    •    속성
    •    지표
    •    P
    •   
    •    C
    •    M
    •    Size
    •    Line
    •   of
    •   Code
    •    O
    •    O
    •    O
    •    Instability
    •   /
    •   Abstractness
    •    O
    •    Cohesion
    •    Lack
    •   of
    •   Cohesion
    •   of
    •   Method
    •    O
    •    DSM
    •    O
    •    O
    •    O
    •    Relation
    •   Chart
    •    Dependency
    •    O
    •    O
    •    O
    •    Tangled
    •    O
    •    Component
    •   Dependency,
    •   CCD,
    •   ACD
    •    O
    •    Depth
    •   of
    •   Inheritance
    •   Tree
    •    Response
    •    O
    •    Number
    •   Of
    •   Children
    •   in
    •   Tree
    •    Branch
    •   
    •    F
    •    O
    •    Cyclomatic
    •   Complexity
    •    O
    •    Weight
    •   Method
    •   for
    •   Class
    •    O
    •    Response
    •   For
    •   a
    •   Class
    •    O
    •   
    • 
    •    Positive
    •   Space
    •   
    •    
    •    핵심
    •   가치를
    •   찾아라..
    •   
    • 
    •    Good
    •   Shape와
    •   함께..
    •    
    •    저는
    •   현재
    •   전체를
    •   대변하는
    •   
    •    가장
    •   큰
    •   원칙이라고
    •   생각합니다.
    •   
    • *    Roughness  
    • 3.  Good  Shape   4.  Levels  of  Scale   1.  Posi<ve     Space   2.  Roughness   5.  Not-­‐Separateness   6.  Strong     Centers   7.Boundaries   8.  Contrast   9.  Void   11.  Simplicity     Inner  Calm   10.  Deep  Interlock   Ambiguity   10.  Echoes   10.  Alterna<ng  Repe<<on   10.  Local  Symmetries   10.  Gradients  
    • 견고함이란..
    •   
    • 내가
    •   만난
    •   문제들..
    •   
    • 왜
    •   이런
    •   일이..
    •    직급
    •    음식
    •   
    •    사내
    •   
    •    동호회
    •   
    •   
    • 이기적인
    •   감정을
    •   버릴수
    •   있는
    •   
    •    팀원들이
    •   구성될수
    •   있는
    •   문화가
    •   중요
    •   
    • 10  Commandments   of     Egoless   Programming      
    • 비자아적인
    •   프로그래밍
    •   10계명
    •   
    •    자신도
    •   실수
    •   할
    •   수
    •   있다는
    •   것을
    •   이해하고
    •   받아
    •    들일줄
    •   알아야
    •   한다.
    •    
    •    너의
    •   프로그램은
    •   너
    •   자신이
    •   아니다.
    •    
    •    리뷰의
    •   중요한
    •   것은
    •   문제를
    •   발견하는
    •   것이라는
    •    것을
    •   기억하라.
    •   문제가
    •   발견되어도
    •   당신
    •   개인
    •    문제로
    •   적용하지는
    •   않는다.
    •   
    • 비자아적인
    •   프로그래밍
    •   10계명
    •   
    •    아무리
    •   당신이
    •   그것에
    •   대해서
    •   자세히
    •   알아도
    •   세상 에는
    •   당신보다
    •   많이
    •   아는
    •   사람이
    •   항상
    •   존재한다.
    •    
    •    타인과
    •   상의
    •   없이
    •   코드를
    •   다시
    •   쓰지
    •   마라.
    •    
    •    당신보다
    •   지식이
    •   없는
    •   사람이라도,
    •   존중,
    •   인내하는
    •    습관을
    •   길러라.
    •    
    •    세상에서
    •   변하지
    •   않는
    •   것은
    •   '변화'뿐이다.
    •   
    • 비자아적인
    •   프로그래밍
    •   10계명
    •   
    •    심각한
    •   불편과는
    •   싸울
    •   수
    •   없으니,
    •   새로운
    •   도전으로
    •    요구사항,
    •   플랫폼,
    •   도구의
    •   변화를
    •   받아들여라.
    •    
    •    권위를
    •   낳는
    •   것은
    •   직함(위치)이
    •   아니라
    •   지식이다. 당신이
    •   믿고
    •   있는
    •   신념과
    •   싸워라.
    •   그러나
    •   패배는
    •   우 아하게
    •   받아들이자.
    •    
    •    고정관념에서
    •   벗어나야
    •   발전할
    •   수
    •   있다.타인과
    •   적 극적으로
    •   커뮤니케이션하라.
    •   비난한다면
    •   사람이
    •    아니라
    •   코드에게
    •   하라
    •   
    • 이기적인
    •   팀의
    •   
    •    
    •    
    •   아키텍처를
    •   보여드립니다.
    •   
    • 리버싱한
    •   결과들  
    • 리버싱한
    •   결과들  
    • Facebook
    •   아키텍쳐
    •   -
    •   Stan4J  
    • Facebook
    •   Check
    •   In
    •   왜
    •   이럴까?
    •   
    • FACEBOOK
    •   아키텍쳐
    •   -
    •   STAN4J  
    • Facebook
    •   아키텍쳐
    •   -오염도
    •    순환참조   크기가 큰 Class  
    • 관리
    •   불가능한
    •   순환참조
    •    1.  Package 간 의존성 증가 2.  모듈 중 일부분 변화로 인하여 전체적인 영향을 미칠 수 있음  
    • Distance   Over
    •   Engineering
    •   
    • Facebook
    •   외부
    •   라이브러리
    •   
    • 
    •    Facebook
    •   외부
    •   라이브러리
    •   참조구조 
    •   
    •   
    •   
    •   ORCA
    •    Jackson
    •    Jayway/jsonpath
    •    
    •   
    •   
    •   
    •   KATANA
    •    Json-simple
    •    Google-inject
    •    acra
    •    Findbugs
    •   
    • Facebook
    •   App
    •   C&C
    •   View
    •    etc.   <<component>>   feed   <<component>>   friends   <<component>>   composer   <<component>>   dash   <<component>>   feed   <<component>>   giTs   <<component>>   debugger   <<component>>   dalvik  wrapper   <<component>>   ui   applica<on  (orca-­‐  범고래)   u<l  (katana  -­‐  도검 )   ui  wrapper   <<component>>   compose   <<component>>   messageview   <<component>>   acDvity  cleaner   <<component>>   plaMorm  dialog   <<component>>   login   <<component>>   database   <<component>>   user  registraDon   <<component>>   profile  list   <<component>>   face  detecDon   <<component>>   phone   <<component>>   protocol   <<component>>   AuthorHelper   <<component>>   Fragment  Factory   <<component>>   bug  report   <<component>>   cache   <<component>>   pager   Install  Messenger   Apk  Injector   <<component>>   Fragment  AcDvity   <<component>>   audio   <<component>>   common  ui   <<component>>   media   <<component>>   place   <<component>>   pager   <<component>>   sms   <<component>>   Dmeline   <<component>>   photo   <<component>>   find  friends   <<component>>   composer   <<component>>   camera   <<component>>   thread   <<component>>   faceweb   <<component>>   events   <<component>>   contacts   <<component>>   server   <<component>>   plaMorm   <<component>>   view   <<component>>   ui   <<component>>   fragment  factory   <<component>>   CompaDbility     external  library   <<component>>   service   <<component>>   uDl   <<component>>   JSON  FormaHer   <<component>>   JSON  Handler   <<component>>   binding   <<component>>   provider   <<component>>   DI  Container   <<component>>   Crash  Reporter    
    • 만약
    •   바꾼다면
    •   
    • Roughness
    •   지표
    •    속성
    •    지표
    •    P
    •   
    •    C
    •    M
    •    Size
    •    Line
    •   of
    •   Code
    •    O
    •    O
    •    O
    •    Instability
    •   /
    •   Abstractness
    •    O
    •    Cohesion
    •    Lack
    •   of
    •   Cohesion
    •   of
    •   Method
    •    O
    •    DSM
    •    O
    •    O
    •    O
    •    Relation
    •   Chart
    •    Dependency
    •    O
    •    O
    •    O
    •    Tangled
    •    O
    •    Component
    •   Dependency,
    •   CCD,
    •   ACD
    •    O
    •    Depth
    •   of
    •   Inheritance
    •   Tree
    •    Response
    •    O
    •    Number
    •   Of
    •   Children
    •   in
    •   Tree
    •    Branch
    •   
    •    F
    •    O
    •    Cyclomatic
    •   Complexity
    •    O
    •    Weight
    •   Method
    •   for
    •   Class
    •    O
    •    Response
    •   For
    •   a
    •   Class
    •    O
    •   
    • *
    •   Good
    •   Shape
    •   
    • 견고한
    •   시스템은
    •   
    •    
    •    기본
    •   요소(Primitive
    •   Element)부터
    •   
    •    
    •    거대한
    •   구조의
    •   시스템
    •   아키텍쳐까지
    •   
    •    
    •    잘
    •   설계되고,
    •   잘
    •   구현되어야
    •   한다.
    •   
    • Roles  &  Paferns  of  Collabora<on  
    • Layers
    •   
    • Sub
    •   Assemblies
    •   ,
    •   Modules
    •   
    •   
    • Good
    •   Shape
    •   지표들
    •    속성
    •    지표
    •    P
    •   
    •    C
    •    M
    •    Size
    •    Line
    •   of
    •   Code
    •    O
    •    O
    •    O
    •    Instability
    •   /
    •   Abstractness
    •    O
    •    Cohesion
    •    Lack
    •   of
    •   Cohesion
    •   of
    •   Method
    •    O
    •    DSM
    •    O
    •    O
    •    O
    •    Relation
    •   Chart
    •    Dependency
    •    O
    •    O
    •    O
    •    Tangled
    •    O
    •    Component
    •   Dependency,
    •   CCD,
    •   ACD
    •    O
    •    Depth
    •   of
    •   Inheritance
    •   Tree
    •    Response
    •    O
    •    Number
    •   Of
    •   Children
    •   in
    •   Tree
    •    Branch
    •   
    •    F
    •    O
    •    Cyclomatic
    •   Complexity
    •    O
    •    Weight
    •   Method
    •   for
    •   Class
    •    O
    •    Response
    •   For
    •   a
    •   Class
    •    O
    •   
    • *  Level  of  Scale  
    • 3.  Good  Shape   4.  Levels  of  Scale   1.  Posi<ve     Space   2.  Roughness   5.  Not-­‐Separateness   6.  Strong     Centers   7.Boundaries   8.  Contrast   9.  Void   11.  Simplicity     Inner  Calm   10.  Deep  Interlock   Ambiguity   10.  Echoes   10.  Alterna<ng  Repe<<on   10.  Local  Symmetries   10.  Gradients  
    • 
    •   Josef
    •   Albers의
    •   Untitled1997  
    • MECE
    •   
    •    (상호배제와
    •   전체포괄)
    •    Mutually     Exclusive  and   Collec<vely   Exhaus<ve    
    • 어디서
    •   많이
    •   본
    •   MECE..
    •   
    • 소스코드는
    •   
    •    MECE(상호배제와
    •   전체
    •   포괄)의
    •   원칙에
    •   
    •   따라
    •   구성
    •   
    • 안드로이드는
    •   잘
    •   되어
    •   있을까?
    •   
    • Android
    •   초창기
    •   버젼
    •   
    • [Google  Services]   Google  Play  In-­‐app  Billing   GCM(Google  Cloud  Messaging)   Google  AnalyDcs   [Android  plaMorm]   Graphics   AnimaDon   Speech   Accounts   widget   View   LocaDon   webkit   Preference   Render  Script   Media   OpenGL   support   Test   zzzz   Database   App   OS   Security   Net   App   Widget   DRM   UDl   SAX   Hardware   (  display,  input,   usb  )   InputmethodService   Bluetooth   NFC   Accessibility   Service   Telephony   [Java  3rd  party  library]   org.apache.hHp   org.json   org.w3c.dom   org.xml.sax   java.sql   java.net   java.nio   java.text   javax.xml   java.lang   java.io   java.math   java.uDl   java.security   junit.framework   [Java  core]  
    • XML을
    •   처리할때?
    •    •  DOM으로
    •   처리하려면?
    •    •  SAX로
    •   처리하려면?
    •   
    • [Google  Services]   Google  Play  In-­‐app  Billing   GCM(Google  Cloud  Messaging)   Google  AnalyDcs   [Android  plaMorm]   Graphics   AnimaDon   Speech   Accounts   widget   View   LocaDon   webkit   Preference   Render  Script   Media   OpenGL   support   Test   zzzz   Database   App   OS   Security   Net   App   Widget   DRM   UDl   SAX   Hardware   (  display,  input,   usb  )   InputmethodService   Bluetooth   NFC   Accessibility   Service   Telephony   [Java  3rd  party  library]   org.apache.hHp   org.json   org.w3c.dom   org.xml.sax   java.sql   java.net   java.nio   java.text   javax.xml   java.lang   java.io   java.math   java.uDl   java.security   junit.framework   [Java  core]  
    • Thread를
    •   다루고
    •   싶어요..
    •   
    • [Google  Services]   Google  Play  In-­‐app  Billing   GCM(Google  Cloud  Messaging)   Google  AnalyDcs   [Android  plaMorm]   Graphics   AnimaDon   Speech   Accounts   widget   View   LocaDon   webkit   Preference   Render  Script   Media   OpenGL   support   Test   zzzz   Database   App   OS   Security   Net   App   Widget   DRM   UDl   SAX   Hardware   (  display,  input,   usb  )   InputmethodService   Bluetooth   NFC   Accessibility   Service   Telephony   [Java  3rd  party  library]   org.apache.hHp   org.json   org.w3c.dom   org.xml.sax   java.sql   java.net   java.nio   java.text   javax.xml   java.lang   java.io   java.math   java.uDl   java.security   junit.framework   [Java  core]  
    • 개발자
    •   문서
    •   없이
    •   개발이
    •   가능할까요?
    •   
    • 우리가
    •   생각한
    •   
    •   Scale
    •   of
    •   Level
    •   
    • Gradient하게
    •   (Step
    •   by
    •   Step)
    •   
    • Android가
    •   가지는
    •   Scale
    •   of
    •   Level
    •   
    • 과거의
    •   교훈!
    •   
    •   .NET
    •   1.0은
    •   어디로?
    •   
    • Erich  Gamma   Eclipse  의 창시자,  GoF의 1인  
    • Eclipse
    •   정말
    •   많이
    •   고민했다..
    •   
    • Spring도
    •   정말
    •   많이
    •   고민했다.
    •   
    • 개방성이
    •   높은
    •   오픈소스
    •   일수록..
    •    Level
    •   of
    •   Scale이
    •   잘되어
    •   있다.
    •    Android
    •    Qt
    •    Symbian
    •    Meego
    •    Mozilla
    •    Linux
    •    Webkit
    •    Eclipse
    •    84   58   58   61   65   23   Openness   68   71  
    • 패키지
    •   /
    •   네임스페이스가
    •   잘
    •   정리되었다
    •    =
    •    
    •   학습하는
    •   사람에게
    •   진입
    •   장벽이
    •   낮다
    •   
    • 건물끼리
    •   서로
    •   조화로운가?
    •   
    • 건물끼리
    •   서로
    •   조화로운가?
    •   
    • 구조물끼리
    •   더
    •   조화로운가?
    •   
    • The
    •   Law
    •   of
    •   Intention
    •    
    •    의식적인
    •   의향(intent)을
    •   통해
    •   
    •    시스템의
    •   조직력을
    •   통제할
    •   수
    •   있다
    •    
    •   
    • Level
    •   of
    •   Scale
    •   지표
    •    속성
    •    지표
    •    P
    •   
    •    C
    •    M
    •    Size
    •    Line
    •   of
    •   Code
    •    O
    •    O
    •    O
    •    Instability
    •   /
    •   Abstractness
    •    O
    •    Cohesion
    •    Lack
    •   of
    •   Cohesion
    •   of
    •   Method
    •    O
    •    DSM
    •    O
    •    O
    •    O
    •    Relation
    •   Chart
    •    Dependency
    •    O
    •    O
    •    O
    •    Tangled
    •    O
    •    Component
    •   Dependency,
    •   CCD,
    •   ACD
    •    O
    •    Depth
    •   of
    •   Inheritance
    •   Tree
    •    Response
    •    O
    •    Number
    •   Of
    •   Children
    •   in
    •   Tree
    •    Branch
    •   
    •    F
    •    O
    •    Cyclomatic
    •   Complexity
    •    O
    •    Weight
    •   Method
    •   for
    •   Class
    •    O
    •    Response
    •   For
    •   a
    •   Class
    •    O
    •   
    • *    Not-­‐Separateness  
    • 3.  Good  Shape   4.  Levels  of  Scale   1.  Posi<ve     Space   2.  Roughness   5.  Not-­‐Separateness   6.  Strong     Centers   7.Boundaries   8.  Contrast   9.  Void   11.  Simplicity     Inner  Calm   10.  Deep  Interlock   Ambiguity   10.  Echoes   10.  Alterna<ng  Repe<<on   10.  Local  Symmetries   10.  Gradients  
    • 무엇이
    •   부족한가?
    •   
    • 나뉘어 지지 않는다..   실세계의
    •   시스템중
    •   완벽히
    •   독립된
    •   시스템은
    •   없다.
    •   
    •    어떤
    •   시스템이라도
    •   작든
    •   크든,
    •   더
    •   큰
    •   시스템
    •   또는
    •   더
    •   작은
    •   시 스템과
    •   연결되어
    •   있다.
    •   
    •   
    •    특정
    •   레벨에만
    •   초첨을
    •   맞추면,
    •   전체적인
    •   Goal이
    •   무너지므로,
    •   
    •    시스템
    •   전체과
    •   일관성을
    •   유지하여
    •   구축해야
    •   된다.
    •   
    •    
    •    설계자는
    •   관계에
    •   초점을
    •   맞추어
    •   살펴볼
    •   필요가
    •   있다.
    •   
    •   
    • 서로
    •   연결되어
    •   있다
    •    Pattern
    •   Languages의
    •   철학과
    •   일맥
    •   상통
    •    
    •    Fault
    •   Tolerant
    •   Pattern의
    •   저자인
    •   Bob은
    •   특정
    •    문제를
    •   해결하기
    •   위해
    •   패턴을
    •   적용하다
    •   보니,
    •    Side
    •   Effect가
    •   발생해
    •   그
    •   문제를
    •   해결하기
    •   부수 적인
    •   패턴
    •   또는
    •   Idiom이
    •   존재한다.
    •   
    • 내고장성
    •   서버의
    •   아키텍처
    •   
    • 분산
    •   객체
    •   서버의
    •   아키텍처
    •   
    • 심지어
    •   사람을
    •   다루는
    •   것도..
    •   연결되어
    •   있다.
    •   
    • 소프트웨어에서 관계는..  
    • Circular  Dependency (상호참조) 조심!     •  Component  A  depends  on  component  B    and   •  Component  B  depends  on  component  A  (even  indirectly).  
    • 해결책은
    •   레이어
    •   (계층화)
    •   
    •   
    • 해결책은
    •   레이어
    •   (계층화)
    •   
    •   
    • Dependency  Management
    • Relation
    •   Chart로
    •   
    •    잘
    •   계층화된
    •   구조인지
    •   본다
    •   
    •   
    • Distance
    •   
    • Tangled
    •   
    • Dependency
    •   Structure
    •   Matrix
    •   
    • Not-Separateness
    •   지표
    •    속성
    •    지표
    •    P
    •   
    •    C
    •    M
    •    Size
    •    Line
    •   of
    •   Code
    •    O
    •    O
    •    O
    •    Instability
    •   /
    •   Abstractness
    •    O
    •    Cohesion
    •    Lack
    •   of
    •   Cohesion
    •   of
    •   Method
    •    O
    •    DSM
    •    O
    •    O
    •    O
    •    Relation
    •   Chart
    •    Dependency
    •    O
    •    O
    •    O
    •    Tangled
    •    O
    •    Component
    •   Dependency,
    •   CCD,
    •   ACD
    •    O
    •    Depth
    •   of
    •   Inheritance
    •   Tree
    •    Response
    •    O
    •    Number
    •   Of
    •   Children
    •   in
    •   Tree
    •    Branch
    •   
    •    F
    •    O
    •    Cyclomatic
    •   Complexity
    •    O
    •    Weight
    •   Method
    •   for
    •   Class
    •    O
    •    Response
    •   For
    •   a
    •   Class
    •    O
    •   
    • *  Strong  Center  
    • 3.  Good  Shape   4.  Levels  of  Scale   1.  Posi<ve     Space   2.  Roughness   5.  Not-­‐Separateness   6.  Strong     Centers   7.Boundaries   8.  Contrast   9.  Void   11.  Simplicity     Inner  Calm   10.  Deep  Interlock   Ambiguity   10.  Echoes   10.  Alterna<ng  Repe<<on   10.  Local  Symmetries   10.  Gradients  
    • Responsibility  Driven  Design  
    • 살아
    •   있는
    •   
    •   모든
    •   것들은,
    •   
    •    
    •    각기
    •   다른
    •   레벨의
    •   구조를
    •   가지고
    •   있고,
    •   
    •    
    •    이
    •   각기
    •   다른
    •   구조들은
    •   
    •    각기
    •   개별적인
    •   자기
    •   고유의
    •   초점을
    •   
    •    가지고
    •   있다.
    •   
    • Layered  Architecture  
    • Role  Stereotypes     •  •  •  •  •  •    Informa<on  holder—knows  and  provides  informa<on.   Structurer—maintains  rela<onships  between  objects.   Service  provider—performs  work  on  demand.   Coordinator—reacts  to  events  by  delega<ng  to  others.   Controller—makes  decisions  and  directs  others’  ac<ons.   Interfacer—transforms  informa<on  and  requests   between  dis<nct  
    • Somware에서 Center란?   •  상호작용 패턴들과 잘 정의된 역할들   •  Control  Centers   •  Domain  Models  :     –  En<ty들,  Value들,  Aggregate  Root들 간의 Domain  과 Rela<onship들   •  Abstract  classes  와  Inheritance  계층구조  
    • Control  Center   a  place  where  objects  charged  with  controlling   and  coordina<ng  reside     centralized delegated dispersed
    • Strong
    •   Center를
    •   잘
    •   찾기
    •   위해서는..
    •   
    • Walking
    •   Skeleton
    •    
    •    Quality
    •   Attribute
    •   Workshop
    •   
    • Size
    •   of
    •   Component
    •   로
    •   LOC
    •   를
    •   본다
    •   
    • 실
    •   사례
    •   ­–
    •   인수
    •   인계
    •   없이
    •   기능
    •   추가해라!!
    •    지나친
    •   상호
    •   참조,
    •   
    •    
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •    유지
    •   보수
    •   어려운
    •   네이밍
    •    
    •    
    •    
    •    
    •    
    •    
    •    
    •    버전이
    •   수시로
    •   바뀌는
    •   오픈소스
    •   라이브러리의
    •   직접적인
    •   의존성
    •   높음
    •   
    • 네이밍만으로 직관성을 높여라.     비지니스
    •   로직별로
    •   
    •    컴포넌트화
    •   하여
    •   
    •    유지보수성
    •   증가
    •   
    • Simple
    •   Framework의
    •   예
    •   
    •    이중
    •   데이터를
    •   마샬링(변환)하는
    •   
    •    녀석은
    •   무엇일까요?
    •   
    • 어디에
    •   무슨
    •   기능이
    •   있는지
    •   알게.
    •   
    •    네이밍과
    •   Level을
    •   잘
    •   나누어라!
    •   
    • Strong
    •   Center
    •   지표
    •    속성
    •    지표
    •    P
    •   
    •    C
    •    M
    •    Size
    •    Line
    •   of
    •   Code
    •    O
    •    O
    •    O
    •    Instability
    •   /
    •   Abstractness
    •    O
    •    Cohesion
    •    Lack
    •   of
    •   Cohesion
    •   of
    •   Method
    •    O
    •    DSM
    •    O
    •    O
    •    O
    •    Relation
    •   Chart
    •    Dependency
    •    O
    •    O
    •    O
    •    Tangled
    •    O
    •    Component
    •   Dependency,
    •   CCD,
    •   ACD
    •    O
    •    Depth
    •   of
    •   Inheritance
    •   Tree
    •    Response
    •    O
    •    Number
    •   Of
    •   Children
    •   in
    •   Tree
    •    Branch
    •   
    •    F
    •    O
    •    Cyclomatic
    •   Complexity
    •    O
    •    Weight
    •   Method
    •   for
    •   Class
    •    O
    •    Response
    •   For
    •   a
    •   Class
    •    O
    •   
    • *    Boundary  
    • Center의
    •   고유성을
    •   강화시키고,
    •   
    •    
    •    Center와
    •   Center
    •   주위의
    •   
    •    연관되어진
    •   것들의
    •   경계를
    •   정하는
    •   작업
    •   
    • 아키텍트의
    •   초점은
    •   
    •    경계와
    •   인터페이스에
    •   있다.
    •    Einar
    •   landre  
    • 왜
    •   경계가
    •   중요한가?
    •    
    •   돈
    •   주는
    •   갑(+이해당사자)와
    •   
    •   협의하는
    •   구간
    •   
    •   
    • 3.  Good  Shape   4.  Levels  of  Scale   1.  Posi<ve     Space   2.  Roughness   5.  Not-­‐Separateness   6.  Strong     Centers   7.Boundaries   8.  Contrast   9.  Void   11.  Simplicity     Inner  Calm   10.  Deep  Interlock   Ambiguity   10.  Echoes   10.  Alterna<ng  Repe<<on   10.  Local  Symmetries   10.  Gradients  
    • Boundaries  in  SW   •  Domain  Driven  Design   –  Context  Model  ,  Context  Mapping   –  Translator,  An<-­‐Corrup<on  Layer  (변질 방지)   •  Interfaces  /  Contractual  Agreements   •  Aggregate  Roots  (Component)   •  Subclass/Superclass  Responsibili<es  &   Obliga<ons  
    • Domain  Driven  Design  
    • Ubiquitous  Language  
    • Context  Map  
    • Shared  Kernel  
    • 모델의 무결성을 보전하는 법  
    • Anti-Corruption
    •   Layer
    •   
    •    (변질방지
    •   계층)
    •   
    • (경험적
    •   차트)
    •   
    •    Domain
    •   Model
    •    한번
    •   만들면
    •   관리
    •   비용은
    •   적게듬
    •    
    •   
    • (경험적
    •   차트)
    •   
    •    Domain
    •   Model
    •   구축
    •   비용이
    •   듬
    •   
    • DDD
    •   도입시
    •   Target
    •   User를
    •   고려해라
    •    또
    •   다른
    •   진입장벽이
    •   될수
    •   있다.
    •   
    •   (Krzysztof
    •   Cwalina)
    •    여러분을
    •   좋아하는
    •   사용자들을
    •   위해
    •   설계하는
    •   것은
    •   쉽지만,
    •   
    •    여러분을
    •   좋아하지
    •   않는
    •   누군가를
    •   위해
    •   설계한다는
    •   것은
    •   매우
    •   어렵다.
    •   
    •    도메인
    •   전문가들(domain
    •   experts)이
    •   설계한
    •   
    •   많은
    •   Framework(API)
    •   들이
    •   있지만,
    •   솔직히
    •    얘기해서
    •   그
    •   Framework(API)들은
    •   도메인
    •   전문가에게만
    •   좋다.
    •   
    •    대부분의
    •   개발자들은
    •   도메인의
    •   전문가가
    •   될
    •   것도
    •   아니며,
    •   현재
    •   어플리케이션(modern
    •    applications)에
    •   적용되는
    •   모든
    •   기술의
    •   전문가가
    •   되려고
    •   하는
    •   것도
    •   아니다.
    •    
    •    오히려
    •   도메인
    •   특화된
    •   용어로
    •   인해
    •   굉장한
    •   학습
    •   곡선을
    •   만들게
    •   된다.
    •   
    • Components  is..   ..
    •   a
    •   set
    •   of
    •   types
    •   that
    •   ship
    •   and
    •   evolve
    •   as
    •   a
    •   unit .
    •   
    • Domain  Aggregates  (DDD)       A domain aggregate is a cluster of associated objects that is treated as a unit for the purpose of data changes <<Aggregate Root>>    Engine     The aggregate root has responsibility for managing access to its parts 4  Wheel                 Position 1 <<Aggregate Root>>      Car    1    4     Tire                        Customer
    • 다양한
    •   관점들
    •   ­–
    •   Zachman
    •   Framework
    •   
    • Boundary
    •   지표
    •    속성
    •    지표
    •    P
    •   
    •    C
    •    M
    •    Size
    •    Line
    •   of
    •   Code
    •    O
    •    O
    •    O
    •    Instability
    •   /
    •   Abstractness
    •    O
    •    Cohesion
    •    Lack
    •   of
    •   Cohesion
    •   of
    •   Method
    •    O
    •    DSM
    •    O
    •    O
    •    O
    •    Relation
    •   Chart
    •    Dependency
    •    O
    •    O
    •    O
    •    Tangled
    •    O
    •    Component
    •   Dependency,
    •   CCD,
    •   ACD
    •    O
    •    Depth
    •   of
    •   Inheritance
    •   Tree
    •    Response
    •    O
    •    Number
    •   Of
    •   Children
    •   in
    •   Tree
    •    Branch
    •   
    •    F
    •    O
    •    Cyclomatic
    •   Complexity
    •    O
    •    Weight
    •   Method
    •   for
    •   Class
    •    O
    •    Response
    •   For
    •   a
    •   Class
    •    O
    •   
    • *    Contrast  
    • 시스템을
    •   구축할때,
    •   
    •    
    •    무엇이
    •   핵심
    •   기능
    •   (Strong
    •   Center)인지
    •   
    •   
    •    어디까지가
    •   경계(Boundaries)인지
    •    
    •    명확한
    •   Contrast(Interface나
    •   Namespace)를
    •   만들어 라.
    •    
    •    
    •   
    • 명확하게
    •   객체의
    •   역할을
    •   나누어라.
    •    •  Input/Output   •  Producer-­‐Consumer   •  Transmifer-­‐Receiver    
    • 좋은
    •   시스템을
    •   구축하기
    •   위해서는
    •   
    •    큰
    •   그림자
    •   부터
    •   작은
    •   그림자
    •   까지
    •   다
    •   보아야
    •   한다.
    •   
    •   
    • 이거
    •   어때
    •   ­–
    •   How
    •   About
    •   분석
    •   사례
    •   
    •    https://github.com/recomio/howabout-android
    •     
    • 두
    •   가지의
    •   스트리밍
    •   서비스를
    •   이용해
    •   음악
    •   재생.  
    • 이거
    •   어때
    •   앱
    •   아키텍처   
    •   spring-android
    •   
    •    (RESTful)   
    •   ViewPagerIndicator
    •   
    •    (뷰페이저)   
    •   RoboGuice
    •   
    •    (인스턴스
    •   인젝션)   
    •   Jackson
    •   
    •    (JSON)   ActionBarSherlock
    •   
    •    (액션바)   
    •   Flurry
    •   
    •    (트래픽
    •   분석)   Universal
    •   Image
    •   Loader
    •   
    •    (이미지
    •   로딩)   
    •   adlibr
    •   
    •    (광고)   
    •   RoboSpice
    •   
    •    (비동기
    •   네트워킹)  
    • 이거
    •   어때
    •   ­–
    •   오염도  
    • 이거
    •   어때
    •   ­–
    •   Tangled
    •   (Circular
    •   Dependency)
    •   
    • 이거
    •   어때
    •   ­–
    •   Cyclomatic
    •   Complexity  
    • 이거
    •   어때
    •   앱
    •   아키텍처   
    •   spring-android
    •   
    •    (RESTful)   
    •   ViewPagerIndicator
    •   
    •    (뷰페이저)   
    •   RoboGuice
    •   
    •    (인스턴스
    •   인젝션)   
    •   Jackson
    •   
    •    (JSON)   ActionBarSherlock
    •   
    •    (액션바)   
    •   Flurry
    •   
    •    (트래픽
    •   분석)   Universal
    •   Image
    •   Loader
    •   
    •    (이미지
    •   로딩)   
    •   adlibr
    •   
    •    (광고)   
    •   RoboSpice
    •   
    •    (비동기
    •   네트워킹)  
    • 새롭게
    •   아키텍처
    •   계층화
    •   적용
    •   
    • Encapsulation
    •   와
    •   Contrast
    •    캡슐화
    •   ,
    •   정보
    •   은닉
    •   
    •   
    •    
    •    얼마나
    •   꽁꽁
    •   감출
    •   것이냐가
    •   아니라.
    •   
    •    
    •    얼마나
    •   적절히
    •   노출하냐가
    •   캡슐화의
    •   핵심.
    •    
    •    
    •    
    •   
    • 어느
    •   것이
    •   
    •   
    •    적절한
    •   캡슐화
    •   일까요?
    •   
    • Contrast
    •   지표
    •    속성
    •    지표
    •    P
    •   
    •    C
    •    M
    •    Size
    •    Line
    •   of
    •   Code
    •    O
    •    O
    •    O
    •    Instability
    •   /
    •   Abstractness
    •    O
    •    Cohesion
    •    Lack
    •   of
    •   Cohesion
    •   of
    •   Method
    •    O
    •    DSM
    •    O
    •    O
    •    O
    •    Relation
    •   Chart
    •    Dependency
    •    O
    •    O
    •    O
    •    Tangled
    •    O
    •    Component
    •   Dependency,
    •   CCD,
    •   ACD
    •    O
    •    Depth
    •   of
    •   Inheritance
    •   Tree
    •    Response
    •    O
    •    Number
    •   Of
    •   Children
    •   in
    •   Tree
    •    Branch
    •   
    •    F
    •    O
    •    Cyclomatic
    •   Complexity
    •    O
    •    Weight
    •   Method
    •   for
    •   Class
    •    O
    •    Response
    •   For
    •   a
    •   Class
    •    O
    •   
    • *
    •   
    •   Void
    •   
    • 3.  Good  Shape   4.  Levels  of  Scale   1.  Posi<ve     Space   2.  Roughness   5.  Not-­‐Separateness   6.  Strong     Centers   7.Boundaries   8.  Contrast   9.  Void   11.  Simplicity     Inner  Calm   10.  Deep  Interlock   Ambiguity   10.  Echoes   10.  Alterna<ng  Repe<<on   10.  Local  Symmetries   10.  Gradients  
    • 여백의
    •   미..
    •   
    • 여백이
    •   있어야
    •   
    •   시스템이
    •   확장가능하고
    •   성장할
    •   수
    •    있다.
    •   
    •    
    •    즉
    •   시스템이
    •   
    •   
    •    요구사항을
    •   계속
    •   받아들이고,
    •   성장하기
    •   위해
    •   
    •   
    •    어떠한
    •   변화를
    •   흡수할수
    •   있게
    •   확장할
    •   수
    •    있는
    •   공간을
    •   구성해야
    •   한다.
    •   
    •   
    • 왜
    •   Layer를
    •   사용하는가?
    •   
    • 왜
    •   Interface를
    •   쓰는가?
    •   
    • Parameter
    •   Object는..
    •   
    • Strong
    •   Center는
    •   VOID가
    •   필수
    •   조건..
    •   
    •   
    • Strong
    •   Center에게는
    •   추상화가
    •   필수
    •   
    • Library
    •   vs
    •   Framework
    •    ApplicaDon  Block   DATABASE   App  Specific   InvocaDons   Logic       Event     Loop     SelecDons     OO  Design   MATH   NETWORKING   GRAPHICS   Singleton   Reactor   State     AcDve  Object     NETWORKING   ADTs   GUI   MATH   Reactor   InvocaDons   App  Specific   Logic   Callbacks   Strategy   Adapter   AcDve  Object   Design  PaHern     State     GUI   ADTs     Singleton     DATABASE   Co n     Event   Loop     Adapter     GRAPHICS    (IoC)   w l  –  Flo tro
    • Contrast
    •   지표
    •    속성
    •    지표
    •    P
    •   
    •    C
    •    M
    •    Size
    •    Line
    •   of
    •   Code
    •    O
    •    O
    •    O
    •    Instability
    •   /
    •   Abstractness
    •    O
    •    Cohesion
    •    Lack
    •   of
    •   Cohesion
    •   of
    •   Method
    •    O
    •    DSM
    •    O
    •    O
    •    O
    •    Relation
    •   Chart
    •    Dependency
    •    O
    •    O
    •    O
    •    Tangled
    •    O
    •    Component
    •   Dependency,
    •   CCD,
    •   ACD
    •    O
    •    Depth
    •   of
    •   Inheritance
    •   Tree
    •    Response
    •    O
    •    Number
    •   Of
    •   Children
    •   in
    •   Tree
    •    Branch
    •   
    •    F
    •    O
    •    Cyclomatic
    •   Complexity
    •    O
    •    Weight
    •   Method
    •   for
    •   Class
    •    O
    •    Response
    •   For
    •   a
    •   Class
    •    O
    •   
    • *
    •   
    •   Simplicity
    •   
    •   &
    •   
    •   Inner
    •   Calm
    •   
    • 3.  Good  Shape   4.  Levels  of  Scale   1.  Posi<ve     Space   2.  Roughness   5.  Not-­‐Separateness   6.  Strong     Centers   7.Boundaries   8.  Contrast   9.  Void   11.  Simplicity     Inner  Calm   10.  Deep  Interlock   Ambiguity   10.  Echoes   10.  Alterna<ng  Repe<<on   10.  Local  Symmetries   10.  Gradients  
    • Simplicity
    •    가능한
    •   시스템을
    •   간결(simple)한
    •   상태로
    •   계속
    •    유지하는
    •   것을
    •   의미
    •   
    •    
    •    즉
    •   시스템이
    •   
    •    Goal과
    •   요구사항을
    •   달성하기
    •   위해
    •   부합하는
    •   
    •    필수적인
    •   요소들로만
    •   구성되어
    •   있어야
    •   한다.
    •   
    • Inner
    •   Calm
    •    간결함을
    •   유지하면
    •   
    •    자연스럽게
    •   구성요소들이
    •   하모니를
    •   이루면서
    •    Inner
    •   Calm(내부가
    •   고요)하게
    •   된다.
    •   
    • 여러
    •   원칙들..
    •    •  Keep
    •   It
    •   Simple
    •   Stupid!!
    •    •  Don’t
    •   Repeat
    •   Yourself
    •    •  Occam’s
    •   Razor
    •   (오컴의
    •   면도날)
    •   
    •    –  같은
    •   현상을
    •   설명하는
    •   두
    •   개의
    •   주장이
    •   있다면,
    •   간 단한
    •   쪽을
    •   선택하라
    •   
    • Occam’s
    •   Razor
    •   (오컴의
    •   면도날)
    •    •  필요이상으로
    •   많은
    •   실체가
    •   존재해서는
    •   안
    •   된 다.
    •   근본
    •   원리는
    •   필수불가결한
    •   것에
    •   국한해야
    •    한다는
    •   것이다.
    •    •  무엇을
    •   설명하기
    •   위해
    •   지나치게
    •   많은
    •   전제나
    •    가정을
    •   끌어들여서는
    •   안
    •   되며,꼭
    •   필요한
    •   것만 으로
    •   제한해야
    •   한다.
    •   
    • 간결함을
    •   유지하기
    •   위해서는..
    •    •  Static
    •   /
    •   Architecture를
    •   분석해라.
    •   
    •    
    •    •  간단한
    •   문제를
    •   복잡하게
    •   풀고
    •   있지
    •   않나요?
    •    •  의심스러운
    •   솔루션을
    •   사용하지
    •   않나요?
    •    •  미래의
    •   요구사항을
    •   추측해서
    •   설계
    •   하지
    •   마라.
    •    •  오늘의
    •   문제는
    •   오늘
    •   풀어라.
    •   
    • Simplicity를
    •   대하는
    •   자세
    •    너무
    •   과도한
    •   Simplicity를
    •   추구하다
    •   보니,
    •   
    •    확장성이나,
    •   변화를
    •   줄수
    •   있는
    •   여지까지
    •   없애서 는
    •   안된다.
    •    
    •    Simplicity의
    •   기준은
    •   
    •    해당
    •   도메인의
    •   사용자가
    •   적은
    •   
    •   Learning
    •   Curve 로도
    •   
    •   쉽게
    •   사용할수
    •   있음이
    •   아닐까?
    •   
    • Simplicity
    •   지표
    •    속성
    •    지표
    •    P
    •   
    •    C
    •    M
    •    Size
    •    Line
    •   of
    •   Code
    •    O
    •    O
    •    O
    •    Instability
    •   /
    •   Abstractness
    •    O
    •    Cohesion
    •    Lack
    •   of
    •   Cohesion
    •   of
    •   Method
    •    O
    •    DSM
    •    O
    •    O
    •    O
    •    Relation
    •   Chart
    •    Dependency
    •    O
    •    O
    •    O
    •    Tangled
    •    O
    •    Component
    •   Dependency,
    •   CCD,
    •   ACD
    •    O
    •    Depth
    •   of
    •   Inheritance
    •   Tree
    •    Response
    •    O
    •    Number
    •   Of
    •   Children
    •   in
    •   Tree
    •    Branch
    •   
    •    F
    •    O
    •    Cyclomatic
    •   Complexity
    •    O
    •    Weight
    •   Method
    •   for
    •   Class
    •    O
    •    Response
    •   For
    •   a
    •   Class
    •    O
    •   
    • *
    •   Deep
    •   Interlock
    •   and
    •   Ambiguity
    •   
    • 3.  Good  Shape   4.  Levels  of  Scale   1.  Posi<ve     Space   2.  Roughness   5.  Not-­‐Separateness   6.  Strong     Centers   7.Boundaries   8.  Contrast   9.  Void   11.  Simplicity     Inner  Calm   10.  Deep  Interlock   Ambiguity   10.  Echoes   10.  Alterna<ng  Repe<<on   10.  Local  Symmetries   10.  Gradients  
    • 깊은 연관성 과 다중성   깊은
    •   연관성
    •   
    •    
    •    깊은
    •   연관성을
    •   가지는
    •   컴포넌트들은
    •   잘
    •   정의된
    •   경계 (Boundaries)를
    •   공유하고
    •   있다.
    •   
    •    경계를
    •   통해
    •   (컴포넌트간에
    •   불필요한
    •   의존성을
    •   만들어내지
    •    않는)
    •   응집성을
    •   생성해
    •   낸다.
    •    
    •    다중성
    •   (Ambiguity)
    •   
    •    Ambiguity는
    •   모호성이
    •   아니라,
    •   다중성
    •   즉
    •   다양한
    •   성격을
    •    가지게
    •   만들라는
    •   의미
    •   
    • 앞에
    •   Boundary..
    •   기억나시죠
    •   
    • Component간의
    •   관계를
    •   
    •    살짝
    •   스케치
    •   해라!
    •   
    • 먼저
    •   Role을
    •   구성하고,
    •   
    •    어떻게
    •   Collaboration할지
    •   고려해라!
    •    
    •    CRC
    •   그려보기
    •   
    • Interface
    •   와
    •   Contract
    •   
    •   잘
    •   정의하는
    •   법
    •    
    •    You
    •   need
    •   Feedback.
    •   
    • API를
    •   설계할때는..
    •    
    •    핵심
    •   시나리오의
    •   
    •    코드
    •   샘플을
    •   먼저
    •   작성해라
    •    
    •    피드백을
    •   받고
    •   다듬어라.
    •    
    •    개선된
    •   코드
    •   샘플을
    •   지원하는
    •   
    •    객체
    •   모델을
    •   정의해라.
    •   
    • Code
    •   Samples
    •   
    • Read
    •   File
    •    sta<c  void  Main(string[]  args)    {                          StreamReader  sr  =  File.OpenText("MyFile.txt");                          string  s  =  sr.ReadLine();                          while  (s  !=  null)                          {                                  s  =  sr.ReadLine();                                  Console.WriteLine(s);                          }    }  
    • Feedback
    •   (Read
    •   File)
    •    sta<c  void  Main(string[]  args)   {          foreach  (string  s  in  File.ReadAllLines("MyFiles.text"))        {                                  Console.WriteLine(s);          }   }
    • Object
    •   Model
    •   Listing
    •   
    • 사용자
    •   시나리오
    •   산출
    •   
    • 사용자
    •   시나리오
    •   산출
    •   
    • 사용자
    •   시나리오
    •   산출
    •   
    • 사용자
    •   시나리오
    •   산출
    •   
    • 친구
    •   리스트
    •   가져오기
    •   (페이스북
    •   API)
    •   
    • 친구
    •   리스트
    •   가져오기
    •    –  Rest
    •   FB
    •    •  Connection<User>
    •   myFriends
    •   =
    •    facebookClient.fetchConnection("me/friends",
    •   User.class);
    •    –  fHalo
    •    •  Connection<Friends>
    •   friends
    •   =
    •   user.friends();
    •   
    • 피드
    •   올리기(페이스북
    •   API)
    •   
    • 피드 올리기 –  Rest
    •   FB
    •    FacebookType
    •   publishMessageResponse
    •   =
    •    facebookClient.publish("me/feed",
    •   
    •    
    •   FacebookType.class,
    •    
    •    
    •   Parameter.with("message",
    •   "RestFB
    •   test"),
    •   
    •    
    •    
    •   Parameter.with(“caption",
    •   “caption
    •   test"),
    •   
    •    
    •    
    •   Parameter.with(“description",
    •   “description
    •   test"),);
    •    
    •    –  fHalo
    •    Feed
    •   feed
    •   =
    •   new
    •   feed();
    •   
    •    feed.setMessage("Message
    •   Test");
    •   
    •    feed.setCaption("Caption
    •   Test");
    •   
    •    feed.setDescription("Description
    •   Test");
    •   
    •    user.publishFeed(me,
    •   feed);
    •   
    • 아키텍처와
    •   예상되는
    •   컴포넌트를
    •   도출한
    •   다음
    •    피드백(코드
    •   사용성)을
    •   통해
    •   다듬기를
    •   하면
    •   된다.
    •   
    •    아래
    •   4가지를
    •   고려해라.
    •    Echoes   Alterna<ng   Repe<<on   Local  Symmetries   Gradients  
    • 동적으로
    •   provider
    •   subscriber의
    •   
    •    관계가
    •   변하는
    •   것을
    •   파악해라!
    •   
    • Push-­‐Push  /  Pull-­‐Pull  
    • Push-­‐Pull  /  Pull-­‐Push  
    • Event  Channel  Architecture   ProxyPushSupplier ProxyPushConsumer
    • Deep
    •   Interlock
    •   and
    •   Ambiguity
    •   지표
    •    속성
    •    지표
    •    P
    •   
    •    C
    •    M
    •    Size
    •    Line
    •   of
    •   Code
    •    O
    •    O
    •    O
    •    Instability
    •   /
    •   Abstractness
    •    O
    •    Cohesion
    •    Lack
    •   of
    •   Cohesion
    •   of
    •   Method
    •    O
    •    DSM
    •    O
    •    O
    •    O
    •    Relation
    •   Chart
    •    Dependency
    •    O
    •    O
    •    O
    •    Tangled
    •    O
    •    Component
    •   Dependency,
    •   CCD,
    •   ACD
    •    O
    •    Depth
    •   of
    •   Inheritance
    •   Tree
    •    Response
    •    O
    •    Number
    •   Of
    •   Children
    •   in
    •   Tree
    •    Branch
    •   
    •    F
    •    O
    •    Cyclomatic
    •   Complexity
    •    O
    •    Weight
    •   Method
    •   for
    •   Class
    •    O
    •    Response
    •   For
    •   a
    •   Class
    •    O
    •   
    • *    Alterna<ng  Repe<<on  
    • 3.  Good  Shape   4.  Levels  of  Scale   1.  Posi<ve     Space   2.  Roughness   5.  Not-­‐Separateness   6.  Strong     Centers   7.Boundaries   8.  Contrast   9.  Void   11.  Simplicity     Inner  Calm   10.  Deep  Interlock   Ambiguity   10.  Echoes   10.  Alterna<ng  Repe<<on   10.  Local  Symmetries   10.  Gradients  
    • 시스템
    •   요소간에
    •   
    •    상호
    •   보완적인
    •   교차,
    •   반복을
    •   만듬으로써,
    •   
    •    
    •    시스템의
    •   행위와
    •   동적인
    •   구조를
    •   
    •    식별,강화,
    •   견고하게
    •   만들수
    •   있다.
    •   
    • 여러
    •   곳에서
    •   물결처럼
    •   반복을
    •   가져오는
    •   
    •    현상을
    •   기반으로
    •   Center들을
    •   강화시켜라.
    •   
    • 일관성있는
    •   제어방식
    •   패턴,
    •   상호작용을
    •   확립해라
    •   
    • Pattern
    •   is
    •   Father
    •   
    •   
    • 우리는
    •   아버지와
    •   비슷한
    •   
    •    생김새,
    •   성격,
    •   습관
    •   등을
    •   
    •    가지고
    •   있다.
    •   
    •   
    • 이미
    •   해결한
    •   문제와
    •    유사한
    •   문제들은..
    •    
    •    유사한
    •   방법(패턴)으로
    •   
    •    해결
    •   할
    •   수
    •   있다.
    •   
    • 지구상의
    •   패턴들..
    •   +
    •   논문
    •   형태
    •   몇
    •   백개..
    •   
    •   
    • 대표적인
    •   사례
    •   몇개..
    •   
    • Broker  (WatchDog)  
    • Broker
    •   패턴
    •    Client-side Proxy transfer message Broker transfer message Server-side Proxy main_event_loop update_repository register_service acknowledgment find_server Find_client Forward_request Forward_response pack_data uppack_data send_request return calls uses API calls pack_data uppack_data call_service send_response uses API calls Client Bridge Server call_server start_task use_Broker_API pack_data uppack_data forward_message transmit_message initialize enter_main_loop run_service use_Broker_API
    • 역사는
    •   되풀이
    •   된다
    •   
    • CORBA  
    • Android  Binder  
    • Composite
    •   Message
    •    Dispatching
    •    Data
    •    Layer
    •    Decomposite
    •   Message UnMarshaling Layer
    •    Composite
    •   Message
    •    Marshaling
    •    Messages
    •   
    • Composite  Message  패턴   PacketInterface Layers * +pushPacket() +popPacket() +headerSize() +makeHeader() FragmentationLayer +headerSize() +makeHeader() +size() +addHeader() Header +size() Packet +size() +addHeader() +marshal() +unmarshal()
    • 역사는 되풀이 된다  
    • Windows  Communica<on  Founda<on  
    • Nefy  
    • Nefy  
    • Alternating
    •   Repetition
    •   지표
    •    속성
    •    지표
    •    P
    •   
    •    C
    •    M
    •    Size
    •    Line
    •   of
    •   Code
    •    O
    •    O
    •    O
    •    Instability
    •   /
    •   Abstractness
    •    O
    •    Cohesion
    •    Lack
    •   of
    •   Cohesion
    •   of
    •   Method
    •    O
    •    DSM
    •    O
    •    O
    •    O
    •    Relation
    •   Chart
    •    Dependency
    •    O
    •    O
    •    O
    •    Tangled
    •    O
    •    Component
    •   Dependency,
    •   CCD,
    •   ACD
    •    O
    •    Depth
    •   of
    •   Inheritance
    •   Tree
    •    Response
    •    O
    •    Number
    •   Of
    •   Children
    •   in
    •   Tree
    •    Branch
    •   
    •    F
    •    O
    •    Cyclomatic
    •   Complexity
    •    O
    •    Weight
    •   Method
    •   for
    •   Class
    •    O
    •    Response
    •   For
    •   a
    •   Class
    •    O
    •   
    • *
    •   Local
    •   Symmetries
    •   
    • 3.  Good  Shape   4.  Levels  of  Scale   1.  Posi<ve     Space   2.  Roughness   5.  Not-­‐Separateness   6.  Strong     Centers   7.Boundaries   8.  Contrast   9.  Void   11.  Simplicity     Inner  Calm   10.  Deep  Interlock   Ambiguity   10.  Echoes   10.  Alterna<ng  Repe<<on   10.  Local  Symmetries   10.  Gradients  
    • 대칭을
    •   통해
    •   
    •    설계의
    •   유사(친밀)성,
    •   응집력,
    •   이해력
    •   향상을
    •   
    •    가져올수
    •   있다.
    •   
    •   
    • THE
    •   POWER
    •   OF
    •   SAMENESS
    •    D  
    • 미국에서
    •   차를
    •   빌릴때..
    •    •  Push
    •   the
    •   seat
    •   all
    •   the
    •   way
    •   back
    •    •  Find
    •   an
    •   NPR
    •   station
    •    •  Find
    •   the
    •   exit
    •    메뉴얼
    •   읽으시나요?
    •   
    • 문은
    •   이렇게
    •   잠궈요
    •   
    • 열쇠 사용법  
    • 안전
    •   벨트
    •   메는
    •   법..
    •   
    • 이런 메뉴얼이 필 요하세요?  
    • 왜
    •   메뉴얼을
    •   안
    •   읽죠?
    •    동일함(대칭)의
    •   힘
    •   
    •   
    • 장황한
    •   인터페이스
    •   가진
    •   객체
    •   
    •   +
    •   Wrapper
    •   객체
    •    
    •    
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   
    •   일관성
    •   있고
    •   유사한
    •   스탭을
    •   가지게
    •   함
    •    
    •   
    • Template
    •   Method화
    •   시켜
    •   
    •   동일한
    •   제어
    •   흐름
    •   확보
    •    
    •    추후
    •   DI로
    •   발전시켜
    •   유연성
    •   확보
    •   
    •   
    • 네이밍
    •    의도를
    •   알수
    •   있는
    •   네이밍
    •    
    •    일반적으로
    •   통용되는
    •   네이밍
    •    
    •    전체적으로
    •   일관성있는
    •   네이밍
    •    
    •   
    • 대칭성
    •   보다
    •   더
    •   중요한
    •   것들
    •    쓰기
    •   쉬운
    •   인터페이스..
    •    
    •    핵심
    •   시나리오의
    •   
    •    코드
    •   샘플을
    •   먼저
    •   작성해라
    •    
    •    피드백을
    •   받고
    •   다듬어라.
    •    
    •    개선된
    •   코드
    •   샘플을
    •   지원하는
    •   
    •    객체
    •   모델을
    •   정의해라.
    •   
    • Local
    •   Symmetries
    •   지표들
    •    속성
    •    지표
    •    P
    •   
    •    C
    •    M
    •    Size
    •    Line
    •   of
    •   Code
    •    O
    •    O
    •    O
    •    Instability
    •   /
    •   Abstractness
    •    O
    •    Cohesion
    •    Lack
    •   of
    •   Cohesion
    •   of
    •   Method
    •    O
    •    DSM
    •    O
    •    O
    •    O
    •    Relation
    •   Chart
    •    Dependency
    •    O
    •    O
    •    O
    •    Tangled
    •    O
    •    Component
    •   Dependency,
    •   CCD,
    •   ACD
    •    O
    •    Depth
    •   of
    •   Inheritance
    •   Tree
    •    Response
    •    O
    •    Number
    •   Of
    •   Children
    •   in
    •   Tree
    •    Branch
    •   
    •    F
    •    O
    •    Cyclomatic
    •   Complexity
    •    O
    •    Weight
    •   Method
    •   for
    •   Class
    •    O
    •    Response
    •   For
    •   a
    •   Class
    •    O
    •   
    • *    Gradients  
    • 3.  Good  Shape   4.  Levels  of  Scale   1.  Posi<ve     Space   2.  Roughness   5.  Not-­‐Separateness   6.  Strong     Centers   7.Boundaries   8.  Contrast   9.  Void   11.  Simplicity     Inner  Calm   10.  Deep  Interlock   Ambiguity   10.  Echoes   10.  Alterna<ng  Repe<<on   10.  Local  Symmetries   10.  Gradients  
    • 
    •    자연이
    •   추구하는
    •   점진적인
    •   변화
    •    
    •    산을
    •   올라가면,
    •   서서히
    •   추워지고,
    •   기압
    •   역시
    •   저 기압으로
    •   바뀝니다.
    •   
    •   
    •    
    •    
    •   
    • 급격한
    •   변화보다
    •   점진적인
    •   변화가
    •   
    •    쉽게
    •   이해할수
    •   있으며,
    •   제어하기도
    •   용이하다.
    •     
    • A라는
    •   기능을
    •   하기
    •   위해
    •   
    •    
    •    수많은
    •   컴포넌트를
    •   호출해야
    •   데이터를
    •   조합해 야
    •   한다면..
    •      A
    •   
    • Component간에
    •   데이터를
    •   주고
    •   받을
    •   때,
    •   
    •    너무
    •   상이한
    •   구조로
    •   되어
    •   있어서,
    •   데이터를
    •   몇 번
    •   변환해서
    •   전달해야
    •   한다면..
    •   
    • Learning
    •   Curve를
    •   줄여라
    •   
    • Text를
    •   처리한
    •   경험으로
    •   
    •    다양한
    •   포멧을
    •   다룰수
    •   있다면
    •   
    • Gradients
    •   지표들
    •    속성
    •    지표
    •    P
    •   
    •    C
    •    M
    •    Size
    •    Line
    •   of
    •   Code
    •    O
    •    O
    •    O
    •    Instability
    •   /
    •   Abstractness
    •    O
    •    Cohesion
    •    Lack
    •   of
    •   Cohesion
    •   of
    •   Method
    •    O
    •    DSM
    •    O
    •    O
    •    O
    •    Relation
    •   Chart
    •    Dependency
    •    O
    •    O
    •    O
    •    Tangled
    •    O
    •    Component
    •   Dependency,
    •   CCD,
    •   ACD
    •    O
    •    Depth
    •   of
    •   Inheritance
    •   Tree
    •    Response
    •    O
    •    Number
    •   Of
    •   Children
    •   in
    •   Tree
    •    Branch
    •   
    •    F
    •    O
    •    Cyclomatic
    •   Complexity
    •    O
    •    Weight
    •   Method
    •   for
    •   Class
    •    O
    •    Response
    •   For
    •   a
    •   Class
    •    O
    •   
    • *    Echoes  
    • 3.  Good  Shape   4.  Levels  of  Scale   1.  Posi<ve     Space   2.  Roughness   5.  Not-­‐Separateness   6.  Strong     Centers   7.Boundaries   8.  Contrast   9.  Void   11.  Simplicity     Inner  Calm   10.  Deep  Interlock   Ambiguity   10.  Echoes   10.  Alterna<ng  Repe<<on   10.  Local  Symmetries   10.  Gradients  
    • 
    •   
    •    공통된
    •   원칙,
    •   주제,
    •   가이드라인이
    •   
    •    (크기의
    •   차이가
    •   있을수
    •   있지만
    •   이것들이)
    •   
    •    반복되어
    •   이루어
    •   짐으로써,
    •   
    •    그
    •   시스템을
    •   더욱
    •   안정되고,
    •   견고하게
    •   만든다
    •   
    • 반복되는
    •   원칙들
    •    •  •  •  •  •  Interface     Metaphor   Inten<onal  names   Rela<onship   Responsibility  –  helper/holder  method,   classes,  component,  services,  excep<on   handling..  
    • Echoes
    •   지표들
    •    속성
    •    지표
    •    P
    •   
    •    C
    •    M
    •    Size
    •    Line
    •   of
    •   Code
    •    O
    •    O
    •    O
    •    Instability
    •   /
    •   Abstractness
    •    O
    •    Cohesion
    •    Lack
    •   of
    •   Cohesion
    •   of
    •   Method
    •    O
    •    DSM
    •    O
    •    O
    •    O
    •    Relation
    •   Chart
    •    Dependency
    •    O
    •    O
    •    O
    •    Tangled
    •    O
    •    Component
    •   Dependency,
    •   CCD,
    •   ACD
    •    O
    •    Depth
    •   of
    •   Inheritance
    •   Tree
    •    Response
    •    O
    •    Number
    •   Of
    •   Children
    •   in
    •   Tree
    •    Branch
    •   
    •    F
    •    O
    •    Cyclomatic
    •   Complexity
    •    O
    •    Weight
    •   Method
    •   for
    •   Class
    •    O
    •    Response
    •   For
    •   a
    •   Class
    •    O
    •   
    • ***
    •   맺음
    •   
    • 3.  Good  Shape   4.  Levels  of  Scale   1.  Posi<ve     Space   2.  Roughness   5.  Not-­‐Separateness   6.  Strong     Centers   7.Boundaries   8.  Contrast   9.  Void   11.  Simplicity     Inner  Calm   10.  Deep  Interlock   Ambiguity   10.  Echoes   10.  Alterna<ng  Repe<<on   10.  Local  Symmetries   10.  Gradients  
    • References   •  •  •  •  •  •  •  •  •  •  
    •    Architecture
    •   vs.
    •   Structural
    •   Engineering
    •   -
    •   http://bit.ly/19RGmOS
    •   
    •   
    •    Renzo
    •   Piano
    •   -
    •   http://bit.ly/19RHRfG
    •    Tjibaou
    •   Culture
    •   Centers
    •   
    •   -
    •   http://bit.ly/19RHiCT
    •   
    •    개구리
    •   지표
    •   +
    •   Uncle
    •   Bob
    •   
    •   -
    •   http://bit.ly/1fm2D7k
    •   
    •    
    •   NIPA
    •   아키텍처
    •   분석
    •   분과
    •   (손영수,
    •   양현철,
    •   정승수,
    •   오혜성)
    •   자료
    •   ­–
    •   추후
    •    공개
    •    A
    •   Timeless
    •   Way
    •   of
    •   Communicating
    •   -
    •   http://slidesha.re/1ewN7BA
    •   
    •    Rebecca
    •   Wirfs-Brock
    •   :
    •   The
    •   Nature
    •   of
    •   Order
    •    Josef
    •   Albers’s
    •   Untitled1997
    •   -
    •   http://bit.ly/1njabvd
    •   
    •    Open
    •   Source
    •   Openness
    •   -
    •   http://bit.ly/oTmEmF
    •   
    •    A
    •   brief
    •   tour
    •   of
    •   RDD
    •   -
    •   
    •   http://bit.ly/1lwytU4
    •   
    •   
    • References   •  •  •  •  •  •  •  Domain
    •   Driven
    •   Design
    •   Quickly
    •   -
    •   http://bit.ly/1et3W4f
    •   
    •    DDD
    •   소개
    •   (MSDN)
    •   -
    •   http://bit.ly/1et5g7c
    •   
    •    DDD
    •   적용에
    •   대한
    •   고민들
    •   -
    •   http://bit.ly/1et58Ey
    •   
    •    Android
    •   Binder
    •   -
    •   http://bit.ly/1kR67Ab
    •   
    •    Positive
    •   &
    •   Negative
    •   Space
    •   -
    •   http://bit.ly/1gLMOdl
    •    Pain
    •   Point
    •   -
    •   http://bit.ly/1cXWaiu
    •   
    •    Egoless
    •   Programming
    •   -
    •   http://bit.ly/1j49K4B
    •   
    •   
    • Q&A
    •