좋은 아키텍처란? 풀려는 문제에 잘 어울리는 설계 코드 구조(ex. 클래스)가 시스템이 어떻게 동작하는지를 잘 이해할 수 있게 보여 준다 변화에 민감: 요구 사항이 진화함에 따라 쉽게 변경이 가능해야 한다 이런 게 쉬워야 한다 이해하기 왜 이렇게 되었는지 이유를 알기 유지하기 테스트하기 더 올바른 경향이 있다 성능 개선 작업을 더 부드럽게 해 준다 좋은 아키텍처의 방해물: 복잡성 복잡성 시스템을 이해하기 어렵고 수정하기 어렵게 만드는 소프트웨어 구조에 관련된 모든 것 복잡성 ≠ 코드의 줄 수 징후 변경 증폭: 작은 변경 → 여러 곳의 많은 편집 인지적 부하: 작은 변경 → 많은 선수 지식을 알아야 함 알 수 없는 무지: 작은 변경 → 알 수 없는 결과들 복잡성을 조장하는 세 가지 요인 의존성 코드가 독립적으로 이해되고 수정될 수 없을 때 없앨 수는 없으나, 최소화되어야 함 불명확함 중요한 정보가 불명확할 때 비용: 지금 10~20% 적게 들더라도 일부 비용은 이자로 영원히 남게 될…

Single Responsibility Principle: 단일 책임 원칙 응집도에 대한 기준 “각 소프트웨어 모듈은 변경의 이유가 단 하나여야만 한다” == “하나의 모듈은 오직 하나의 액터에 대해서만 책임져야 한다” 1974년 다익스트라에 의해 제안된 개념인 관심사의 분리의 다른 표현 하나의 클래스가 하나의 일만 해야 한다는 뜻이 아님에 유의(메소드는 그래야 함) Open-Closed Principle: 개방-폐쇄 원칙 “소프트웨어 모듈은 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다” 열려 있다: 데이터 구조에 필드를 추가하거나, 함수에 새로운 요소를 추가하는 것이 가능해야 함 닫혀 있다: 내부 코드를 변경해도 이를 사용하는 외부 모듈에는 영향을 미치지 않아야 함 멤버 변수를 private / protected로 선언: 내부 데이터의 변경이 클래스 사용자에게 의도치 않은 영향을 주지 않도록 글로벌 변수 피하기: 글로벌 변수를 참조하는 모듈이나 클래스가 외부 값에 의존…