아키텍처 설명 문서가 DRY 원칙을 위반합니까?

DRY 원리 (자신을 반복하지 말 것) 는 "모든 지식은 시스템 내에서 하나의 명백하고 권위있는 표현을 가져야한다"고 말합니다. 대부분의 경우 이것은 코드를 의미하지만 종종 설명서로 확장되기도합니다.

모든 소프트웨어 시스템은 선택 여부에 상관없이 아키텍처를 가지고 있다고합니다. 다시 말해, 구축 한 소프트웨어에는 구조가 있으며 "구축 된"구조는 소프트웨어의 아키텍처입니다. 빌드 된 소프트웨어 시스템에는 아키텍처가 제공되므로 해당 시스템의 아키텍처 설명을 작성하여 DRY 원칙을 위반합니까? 결국, 아키텍처를 알아야한다면 항상 코드를 볼 수 있습니다 ...

생각을 코드에 복제하는 것은 DRY 원칙을 위반합니까?

Geez, 코드를 조사하여 아키텍처를 알 수 있다면 "아키텍처 설명 문서"와 같은 것은 처음에는 없습니다. 그것은 회개가 아니며, 시스템 수준 의 또 다른 수준이며 , 코드에서 사소하게 추론 할 수 없으며 그 반대도 마찬가지입니다. 따라서 DRY를 받아들이더라도 존재하는 모든 권리가 있습니다.

DRY를 단단하고 빠른 규칙으로 사용하지 마십시오. 좋은 일이지만 실제로는 대략적으로 만 근사 할 수 있습니다.

또한 나는 그것이 잘 쓰여지지 않았다고 생각합니다. "반복하지 마십시오"는 의미 적 또는 기능적 변경을하기 위해 소스 텍스트를 여러 곳에서 편집해야하지만 서로 다른 조정 된 내용을 말해야하는 중요한 경우를 다루지 않습니다.

위반하지 않는 계명으로 받아들이 기보다는 왜 그것이 좋은 생각인지 이해하고 그것에 대해 현명한 선택을하는 것이 좋습니다. 여러 곳에서 공동 편집을해야하는 것은 편집자가 실수를 저지르기 때문입니다. 오류없이 변경을 수행하는 데 100 % 신뢰할 수 없습니다. 10 개의 다른 소스 텍스트를 변경해야하고 그 중 9 개만 올바르게 수정 했다면 버그가있는 것 입니다. 따라서 조정 된 변경 횟수를 최소화하기 위해 소스 텍스트를 정렬하는 것이 좋습니다. 버그를 최소화합니다.

우리는 DRY가 계명 ​​중 하나 인 종교에 속하지 않습니다. 약간의 오해의 소지가 있지만 일부 상식을 캡슐화하는 편리한 방법입니다.

아키텍처 설명 또는 소프트웨어 디자인 설명 이 DRY를 위반합니다. 그러나 지난 몇 년간 프로젝트가 진행되고 개발자가 왔다가 나가는 대규모 조직에서는 한 사람이 모든 세부 사항을 머리에 담기에는 시스템이 너무 커서 중요한 문서입니다. 동기화를 유지하는 데 필요한 "반복"의 양은 다음 업데이트 또는 유지 관리 중에 절약 할 수있는 가치가 있습니다.

아키텍처 설명은 DRY 원칙을 위반하지 않습니다.

소프트웨어 시스템에는 아키텍처가 제공됩니다. 또한 많은 클래스에 걸쳐 많은 파일에 걸쳐 있으며 개요에 필요하지 않은 많은 외부 및 세부 사항이 있습니다.

아키텍처 문서는 뉴스 보고서의 첫 번째 단락과 같아야합니다. 개요, 요약, 프로젝트 로드맵입니다.

문서에 날짜를 기입하면 문서 작성 당시의 아키텍처에 대해 설명합니다.

코드는 현재 아키텍처를 나타냅니다.

두 가지 별개의 것-같은 지식이 아닙니다.

문서 작성 시점에서 문서가 아키텍트를 나타내는 것으로 기술되어 있다면, 다른 시점의 시스템에 대한 지식이 다르기 때문에 지식 IMO를 복제하지 않습니다.