• 복잡성

  • 시스템을 이해하거나 유지보수하기 어렵게 만드는 모든 것

  • 필수적인 복잡성/우연적인(accidental) 복잡성이 있음

  • 우연적인 복잡성의 원인들

    • 잘못된 요구사항들 + 의사소통 오류
      • 의존성(강한결합) => 결합을 완전히 피할수는 있지만 느슨한 결합으로 복잡성을 최소화할수는 있음.
      • 모호함(낮은 응집력) - 필요없는 정보, 네이밍, 잘못된/누락된 추상화 등
      • 더 많은 개발자
      • 프로그래밍 언어, 파이브러리, 프레임워크가 커도 생길 수 있음.
      • 너무 이른 최적화 => 오버엔지니어링을 말하는 것 같음.
      • 다른 기타 원인 등등 - 코드스멜들

  • 복잡성을 감지하는 방법

    • Ripple
      -> 코드의 측면이 밀접하게 결합 or 캡슐화 부족 or 종속성이 서로에 대해 너무 많이 알고 있는 것
      -> 단순한 코드 변경으로 보이는 것이 실제로 코드의 여러부분을 수정해야되는 상황
    • 인지 부하 (Cognitive load)
      -> Ripple과 반대로 너무 많은 추상화와 캡슐화를 가지고 있다는 신호
    • 낮은 검색 가능성(Poor discoverability)
      -> 어떤 기능에 특정 로직을 추가해야된다고 할 때 변경해야할 코드를 찾는데 얼마나 걸리는가
    • 낮은 이해도

  • 기술적인 연습들

    • 피드백 - 짝 프로그래밍, TDD
    • 지속적인 프로세스 - 지속적인 통합, 디자인 개선/리팩토링, 작은 릴리즈들
    • Shard understanding (공유 이해..?) - 코딩표준, 모든 구성원이 코드에 책임감을 가져야함, 심플한 디자인, DDD
    • 프로그래머 복지 - 개발자는 주에 40시간 이상 일하면 안됨 ㅎ..

• 소프트웨어 설계의 목표는 고객의 요구에 부응하고 개발자가 효율적인 비용으로 변경할 수 있는 제품을 구축하는 것

• 낮은 수준의 세부지식(클린코드 작성, 효과적은 프로그래밍 패러다임 사용, 설계원칙 준수) 없이는 고급 소프트웨어 설계자가 될 수 없음.

Humans & Code

• Clean Code
  - 우연한(accidental) 복잡성이 거의 없는 코드

  • 읽기 쉬움/테스트가 가능한 코드 등
  • 코딩표준 : 코드베이스에서 일관된 스타일과 접근방식으로 코드를 푸시하는 규칙모음

• 단순한 디자인의 4가지 요소
  1. 모든 테스트 실행

  2. 중복없음
  3. 명확성을 최대화
  4. 적은 요소

• HCD
  - 사용자의 요구,행동,특성,고충,동기를 먼저 생각하는 디자인 철학

  • Discover -> Define -> Design -> Prototype & Test -> Plan & Implement

    여기까지가 108쪽

    ---