목적 : 더 좋은 디자인의 소프트웨어를 만든다. 좋은 디자인의 소프트웨어는 재활용성이 좋고, 테스트하기 편하고, 유지보수하기 편하고, 빌드 타임이 빨라진다

1. 계층구조의 분리
    A.        복합된 계층구조가 등장할 경우
        i.        게임 캐릭터의 계층구조, 3d 그래픽 라이브러리의 계층구조
    B.        서로 다른 시스템의 클래스간의 상속관계를 소유관계로 전환
        i.        game::CGameActor 가 d3dlib::C3dActor 로부터 상속되면 안된다
    C.        각각의 계층구조로 나누어진다
    D.        각각 다른 Manager 에 의해서 소유, 관리된다
        i.        새로운 오브젝트의 생성은 각각의 서브시스템에서 이루어져야 한다

2. 기능의 배치
    A.        2 개의 클래스, A 와 B 의 중간에서 동작하는 메소드가 있을 때, 그 메소드는 어떻게 존재해야 하는가?
        i.        A 의 멤버 함수로 존재하는 경우
        ii.        B 의 멤버 함수로 존재하는 경우
        iii.        A 에도, B 에도 속하지 않는 별개의 함수로 존재하는 경우
    B.        예제 : DirectDraw 와 Bitmap 클래스가 있을 때 DrawBitmap 이라는 메소드는 어떻게 존재해야 하는가?
    C.        생각해볼 사항
        i.        누가 주로 서버의 역할을 하고, 누가 주로 클라이언트의 역할을 하는가
        ii.        주위 다른 클래스를 감안할 경우 얼마나 다양한 관계가 파생되는가?
            1.        Bitmap 이 계속 상속될 경우 (JPG, BMP, GIF 등 or DXTBitmap, RLEBitmap)
        iii.        앞으로 변할 가능성이 있는 쪽은 어느쪽이고, 잘 변하지 않는 쪽은 어느쪽인지?
        iv.        서브시스템간의 관계라면 Pull-type interface 가 바람직하다

3. 패키지화된 디자인
    A.        모듈화가 왜 필요한가에 대한 재확인
    B.        컴포넌트와 패키지
    C.        추상 인터페이스 개념
        i.        자바의 경우 extends 와 implements 가 명시적으로 나뉘어있다
    D.        물리적인 구조
        i.        헤더파일들의 분리 (공개용과 내부용)
        ii.        폴더의 분리

4. Cyclic-Dependency
    A.        CD 가 무엇이고 왜 나쁜가?
        i.        모듈단위 재사용의 장애물
    B.        CD 를 없애기 위한 방법은 무엇인가?
        i.        프로모션
        ii.        디모션
    C.        John Lakos 의 Large scale c++ software design 을 참조하라

5. 작명 센스
    A.        좋은 이름을 붙이지 않는 것의 후유증
    B.        좋은 이름을 짓는 방법
        i.        상식적으로 이해할 수 있는 이름
        ii.        의도에 정확히 부합하는 이름
        iii.        패턴을 이용하라
            1.        패턴 카탈로그에서 내가 만들고자 하는 것이 어떤 패턴에 속하는 것인지 알아낸다 -> 이름을 추출하고, 출처를 적어놓는다

6. 코딩 센스
    A.        주석 달기에 대하여
        i.        주석은 프로그래머의 의도를 설명하는데 쓰여야 한다
        ii.        이미 코드가 충분히 추상적인 레벨에서 프로그래머의 의도를 설명하고 있다면, 주석은 불필요하다
        iii.        코드의 내용이 충분히 추상적인 레벨이 아니라면 (최적화나 기타 이유에 의해서 내용은 같지만 구현 방식이 바뀌게 된다면) 그 내용의 기준이 되는 것이 상단에 달린 주석이 될 것이다
    B.        매직로직
        i.        매직 밸류를 넣는 것이 위험한만큼 매직 로직을 넣는 것도 위험하다.

7. 테스트 우선원칙
    A.        상식적으로 생각하는 소프트웨어의 개발단계 : 분석 – 디자인 – 코드 – 테스트
    B.        실질적으로는 다음과 같아야 한다
        i.        분석 – 테스트 – 디자인 – 테스트 – 코드 – 테스트
        ii.        왜? 오류는 후에 발견될수록 훨씬 더 많은 대가를 치루게 되기 때문이다
    C.        유닛 테스트
        i.        페어프로그래밍시, 드라이버가 만드는 것을 권한다
    D.        리그레션 테스트
    E.        빌드 프로세스와의 통합 (모든 사람은 귀찮아 한다)