アーキテクチャ記述文書はDRY原則の違反ですか？

DRY Principle（Do n't Repeat Yourself）は、「すべての知識は、システム内で単一の明確な権威ある表現を持たなければならない」と述べています。ほとんどの場合、これはコードを指しますが、多くの場合、ドキュメントにも拡張されます。

すべてのソフトウェアシステムには、選択したかどうかに関係なくアーキテクチャがあると言われています。つまり、構築するソフトウェアには構造があり、その「構築された」構造がソフトウェアのアーキテクチャです。 構築されたソフトウェアシステムにはアーキテクチャが付属しているため、そのシステムのアーキテクチャ記述を作成することはDRY原則に違反していますか？ 結局のところ、アーキテクチャを知る必要がある場合は、常にコードを見ることができます...

考えをコードに複製することは、DRYの原則に違反しますか？

Geez、コードを調べるだけでアーキテクチャを知ることができれば、そもそも「アーキテクチャ記述文書」のようなものはありません。これは繰り返しではなく、システム記述の別のレベルであり、コードから簡単に推測することはできません。逆も同様です。そのため、DRYを受け入れても存在する完全な権利があります。

DRYを厳格なルールとして受け取らないでください。それは良いことですが、実際には概算しかできません。

また、それはよく書かれていないと思います。「自分自身を繰り返さないでください」は、セマンティックまたは機能の変更を行うために、複数の場所でソーステキストを編集し、異なるが調整されたものを言う必要があるという等しく重要なケースをカバーしていないようです。

違反されないように戒めと見なすのではなく、なぜそれが良いアイデアであるかを理解し、それについて賢明な選択をする方が良いです。複数の場所で調整された編集を行わなければならないのが悪いのは、編集者であるあなたが間違いを犯すからです。エラーなしで変更を行うことは100％信頼できません。10個の異なるソーステキストの変更を行う必要があり、そのうちの9個だけが正しい場合、バグが発生します。調整された変更の数を最小限に抑えるためにソーステキストを配置するのが良い理由です。バグを最小限に抑えます。

私たちは、乾燥が戒めの一つである宗教に属していません。若干の常識をカプセル化するための、わずかに誤解を招きやすい便利な方法です。

アーキテクチャ記述またはソフトウェア設計記述は、DRYに違反します。しかし、昨年のプロジェクトで開発者が出入りする大規模な組織では、システムが大きすぎて誰もがすべての詳細を頭に入れられないため、これは重要なドキュメントです。同期を保つために必要な「繰り返し」の量は、次の更新または保守中に節約できる労力のために完全に価値があります。

アーキテクチャ記述は、DRY原則に違反しません。

あなたのソフトウェアシステムには確かにアーキテクチャが付属しています。また、多くのクラスの多くのファイルに広がっており、概要には不要な多くの無関係な詳細が含まれています。

アーキテクチャドキュメントは、ニュースレポートの最初の段落のようなものである必要があります。これは、プロジェクトの概要、概要、ロードマップです。

文書の日付を記入すると、執筆時点のアーキテクチャが説明されます。

一方、コードは現在のアーキテクチャを表しています。

2つの異なること-同じ知識ではありません。

ドキュメントが執筆時点でアーキテクチャを表していると述べている限り、別の時点でのシステムに関する知識が異なるため、知識IMOを複製することはありません。