"무 종속주기 없음"규칙 (NDepend)을 얼마나 엄격하게 준수합니까?

약간의 배경 : 팀 리더로서 나는 일주일에 한 번 NDepend를 사용하여 코드의 품질을 확인합니다. 특히 테스트 범위, 코드 라인 및 순환 복잡성 메트릭은 매우 귀중합니다. 그러나 레벨 화 및 종속성주기에 관해서는 조금 걱정이됩니다. Patrick Smacchia에는 레벨 화 목표를 설명 하는 멋진 블로그 게시물 이 있습니다.

명확하게 : "종속주기"에서 두 네임 스페이스 사이의 순환 참조를 이해합니다.

현재 임베디드 인스트루먼트를위한 Windows CE 기반 GUI 프레임 워크에서 작업하고 있습니다. 안드로이드 그래픽 플랫폼을 생각하지만 매우 저가의 인스트루먼트를 고려하십시오. 이 프레임 워크는 약 50.000 줄의 코드를 가진 단일 어셈블리입니다 (테스트 제외). 프레임 워크는 다음 네임 스페이스로 분할됩니다.

• 핵심 탐색 및 메뉴 하위 시스템
• 화면 하위 시스템 (발표자 /보기 / ...)
• 컨트롤 / 위젯 레이어

오늘 나는 반나절을 코드를 적절한 수준으로 가져 오려고 노력했지만 [일반적으로 문제는 없습니다.] 모든 경우에 일부 의존성주기가 존재합니다.

내 질문 : "무 종속주기"규칙을 얼마나 엄격하게 준수합니까? 평준화가 정말로 중요합니까?

필자는 최근 .NET 코드 구성 주제에 대한 Simple-Talk에 게시 된 백서 2 개를 썼습니다 (첫 번째 책은 .NET 어셈블리에 관한 것이고, 두 번째는 네임 스페이스 및 레벨링에 관한 것입니다).

.NET 어셈블리 및 Visual Studio 프로젝트를 통해 코드베이스 파티션

네임 스페이스를 사용하여 .NET 구성 요소 정의

평준화가 정말로 중요합니까?

네!

두 번째 백서에서 인용 한 내용 :

구성 요소 간 종속성 그래프에주기가 포함 된 경우주기에 관련된 구성 요소를 독립적으로 개발하고 테스트 할 수 없습니다. 이로 인해 구성 요소의주기는 포함 된 구성 요소의 엔트로피 합계보다 높은 엔트로피를 갖는 수퍼 구성 요소를 나타냅니다.

(...)

비순환 구성 요소 제약 조건이 지속적으로 존중되는 한, 코드베이스는 학습이 용이하고 유지 보수가 가능합니다.

• 전통적인 건물 건축에서 중력 강도는 낮은 수준의 인공물에 압력을가합니다. 이것은 움직이기 어렵다는 의미에서 '안정적'인 것입니다.
• 소프트웨어 아키텍처에서 비 주기적 구성 요소 아이디어를 준수하면 낮은 수준의 구성 요소에 압력이 가해집니다. 이것은 리팩토링하기가 어렵다는 점에서 더 안정적입니다. 경험적으로 추상화는 구현보다 리팩토링에 덜 영향을받습니다. 이러한 이유로 하위 수준의 구성 요소에는 고통스러운 리팩토링을 피하기 위해 대부분 추상화 (인터페이스 및 열거)가 포함되는 것이 좋습니다.

클래스 또는 네임 스페이스 사이에 순환 종속성을 허용하지 않습니다. C #, Java 및 C ++에서는 인터페이스를 도입하여 항상 순환 클래스 종속성을 중단 할 수 있습니다.

코딩 우선 테스트는 순환 종속성을 도입하기 어렵습니다.

항상 상충 관계입니다. 의존성을 피해야하는 이유를 이해하려면 의존성 비용을 이해해야합니다. 같은 방식으로, 의존성 비용을 이해하면 특정 경우에 가치가 있는지 더 잘 결정할 수 있습니다.

예를 들어 콘솔 비디오 게임에서 우리는 종종 성능상의 이유로 정보와 밀접한 관계가 필요한 종속성에 의존합니다. 예를 들어 판 도구만큼 유연하지 않아도되는 한 괜찮습니다.

하드웨어, OS 또는 디자인 (예 : "우리가 할 수있는 더 단순한 UI"등)에서 실행해야하는 마녀의 제약 조건을 이해하면 쉽게 종속 관계를 수행하지 않아야하며 이해해야하는 부분을 이해하기 쉽게 선택할 수 있어야합니다. 확인.

그러나 분명하고 명확한 이유가 없다면, 가능한 의존성을 피하십시오. 종속 코드는 디버그 세션의 지옥입니다.

이 주제에 대해 논의 할 때마다 참가자는 일반적으로 빌드 타임과 런타임 사이클 사이의 차이를 잃습니다. 전자는 존 라 코스 (John Lakos)가 "물리적 디자인 (physical design)"이라고 언급 한 것이지만 후자는 기본적으로 논의와 관련이 없다 (콜백에 의해 생성 된 것과 같은 런타임 사이클에 매달리지 말라).

John Lakos는 모든 (빌드 타임) 사이클을 제거하는 데 매우 엄격했습니다. 그러나 Bob Martin은 바이너리 (예 : DLL, 실행 파일) 간의 주기만 중요하므로 피해야한다는 태도를 채택했습니다. 그는 바이너리 내의 클래스 들 사이의 주기는별로 중요하지 않다고 생각했다.

나는 개인적으로 Bob Martin의 견해를 가지고 있습니다. 그러나 나는 이러한 사이클이 없으면 다른 사람들이 쉽게 읽고 배울 수 있기 때문에 클래스 간의 사이클에 약간의주의를 기울입니다.

그러나 Visual Studio로 빌드 한 코드는 이진 (기본 코드 또는 관리 코드)간에 순환 종속성을 가질 수 없습니다. 따라서주기와 관련된 가장 심각한 문제가 해결되었습니다. :)

Haskell에서는 빌드 유형 종속성주기가 불편하고 Agda 및 Coq에서는 불가능하기 때문에 거의 전적으로 사용됩니다.