架构描述文件是否违反了DRY原则？

DRY原则（不要重复自己）指出：“每条知识都必须在系统中具有单一，明确，权威的表示形式。” 在大多数情况下，这是指代码，但它通常还扩展到文档。

据说每个软件系统都有一个体系结构，无论您是否选择它。换句话说，您构建的软件具有结构，而“已构建”结构就是软件的体系结构。 由于构建的软件系统具有体系结构，因此创建该系统的体系结构描述是否违反DRY原理？ 毕竟，如果您需要了解架构，那么您始终可以只看一下代码...

将您的想法复制到代码中是否违反DRY原则？

Geez，如果您只是通过研究代码就能了解架构，那么首先就不会出现“架构描述文档”之类的东西。这不是重新定义，而是系统描述的另一个层次，它不能从代码中轻易推导出，反之亦然。因此，即使您拥护DRY，它也具有存在的全部权利。

不要将DRY作为硬性规定。这是一件好事，但是您只能在实践中对其进行近似。

我也认为它写得不好。“不要重复自己”似乎没有涵盖同样重要的情况，即要进行语义或功能上的更改，您将不得不在多个位置编辑源文本，并说出不同但协调的内容。

与其将其视为不可违背的诫命，不如理解它为什么是一个好主意并对此做出明智的选择。必须在多个位置进行协同编辑的原因很糟糕，是您（编辑器）犯了错误。您不能百分百可靠地进行更改而不会出错。如果您必须对10个不同的源文本进行更改，而您只对其中9个进行了正确更改，则说明存在一个bug。这就是为什么安排源文本以最小化协调更改的数量是一件好事的原因。它最大程度地减少了错误。

我们不属于以DRY为戒律之一的宗教。这只是封装某些常识的一种方便但略有误导的方法。

架构说明或软件设计说明确实违反了DRY。但是，在一个大型组织中，去年的项目很多，开发人员来了又去，而且系统太大，以至于任何人都无法将所有细节都掌握在自己的脑海中，这是至关重要的文档。使其保持同步所需的“重复”数量，对于在下一次更新或维护期间节省的精力来说，是完全值得的。

架构描述不违反DRY原理。

当然，您的软件系统带有体系结构。它散布在许多文件中，许多类中，并且具有许多不必要的和详细信息，对于概览而言是不必要的。

您的体系结构文档应类似于新闻报道的第一段：它是项目的大纲，摘要和路线图。

如果您在文档中注明日期，则在撰写本文时它会描述体系结构。

而代码表示当前的体系结构。

两件分开的事情-不相同的知识。

只要您声明该文档在撰写本文时就代表了体系结构，您就不会在复制IMO，因为它在另一个时间点对系统的了解是不同的。