컴포넌트 결합도

컴포넌트 의존성 그래프에 순환이 있어서는 안된다.

숙취 증후군은 많은 개발자가 동일한 소스파일을 수정하는 환경에서 발생한다.

해결책으로 두가지 방법이 있다

일주일에 4일동안은 서로를 신경쓰지 않다가 금요일날 변경된 코드를 통합하여 시스템을 빌드한다.

문제점은 프로젝트가 커지면 금요일 하무많이 끝마치는게 불가능해진다. 통합에 시간이 더걸리기 시작해서 효율성도 나빠진다.

이 문제의 해결책은 개발 환경을 릴리스 가능한 컴포넌트 단위로 분리하는 것이다.

한가지 더 주목할점은 어떤 컴포넌트에서 시작하더라도 의존성 관계를 따라가면서 최초의 컴포넌트로 돌아갈수 없다는 사실이다.

컴포넌트 구조는 하향식으로 설계될 수 없다.

의존성 다이어 그램은 애플리케이션의 빌드가능성과 유지보수성을 보여주는 지도와 같다.

의존성 구조와 관련된 최우선 관심사는 변동성을 격리하는 일이다.

안정성의 방향으로(더 안정된 쪽에) 의존하라.

안정성은 변화가 발생하는 빈도와는 직접적인 관련이 없다.
소프트웨어 컴포넌트를 변경하기 어렵게 만드는 확실한 방법 하나는 수많은 다른 컴포넌트가 해당 컴포넌트에 의존하게 만드는 것이다.

fan-in : 컴포넌트 안으로 들어오는 의존성. 컴포넌트 내부의 클래스에 의존하는 컴포넌트 외부의 클래스 개수
fan-out : 바깥으로 나가는 의존성. 컴포넌트 외부의 클래스에 의존하는 컴포넌트 내부의 클래스 개수
I(불안정성) : I = fan-out / (fan-in+fan-out). [0,1] 범위를 갖는다. 0이면 최고 안정성을 1이면 불안정성을 나타낸다.

모든 컴포넌트가 안정적이어야 하는 것은 아니다.

컴포넌트는 안정된 정도만큼만 추상화 되어야 한다.

참조