是否有可能制定架构指南？如果是这样，它们应该是什么？答案

【问题标题】：Is it possible to have architecture guidelines? If so what should be in them?是否有可能制定架构指南？如果是这样，它们应该是什么？
【发布时间】：2010-11-13 11:05:05
【问题描述】：

和我们有编码标准一样，能不能有架构标准之类的东西？

这些将是我们可以传递给经验不足的程序员的高级原则，因此当他们开始设计更改或小型应用程序时，他们知道我们期望看到的内容，而无需更有经验的程序员进行纠正（请注意，这不是审查，只是尽早防止明显的错误）。

我认为它可能包含诸如“始终规范化您的数据库，除非有明确且明确的不这样做的原因”、“始终分离表示、逻辑和持久性”等内容。

人们是否认为这太高而没有任何实际用途？或者考虑到我们可能被要求编码的各种功能，这样的概括几乎是不可能的？或者可能有用吗？

如果您认为它们有用且现实，您会包括哪些内容？

（如果它有助于澄清我正在考虑为企业风格的业务系统进行 Java/.NET 级编程）。

【问题讨论】：

由于某种原因，这个线程的答案越来越像我提供给我的客户的研讨会，我称之为开发实践研讨会，它也基于 SOLID 并继续进行重构，单元测试等。大声笑。

标签： java .net architecture

【解决方案1】：

SOLID principles 是个不错的起点

【讨论】：

【解决方案2】：

我们确实有架构指南。他们被称为design patterns。这些基本上是正式的架构指南，您可以酌情遵循。

不幸的是，作为一名真正的软件架构师，必须能够决定何时以及如何应用某些模式/指南/实践。这不一定是可自动化或可直接打印的——几乎总是有不止一种方法可以做某事，而且每种方法都有成本和收益。技能在于了解这些方面的全部范围，并预先做出正确的决定。

【讨论】：

设计模式是特定于实现和语言的，所以它们最多是一个“低级设计”问题。架构通常关注更高层次的概念，例如可扩展性、安全性、与其他应用程序的集成等等。
设计模式，真正的设计模式，完全与语言无关。它们是处理特定概念的一种方式，进而允许可扩展性、安全性、集成等。

【解决方案3】：

这很难做到，这就是为什么通常的做法是始终让更资深的团队成员处理架构决策和编码。如果让高级团队成员同时做这两件事不切实际，那么至少让该成员成为设计和审查过程中不可或缺的一部分。

【讨论】：

【解决方案4】：

“总是分开展示，逻辑和持久性”。

除非有充分的理由不这样做。

对于比代码更模糊的架构，这样的规则会很快退化为挥手和退出条款。所以这样的指导方针是可能的，但我认为它们没有用。归根结底，您要依赖建筑师的专业知识和知识——用不成熟的规则（以及谁制定这些规则？）使他或她步履蹒跚，这似乎不是一个好主意。

【讨论】：

我很高兴给出 get out 子句，附带条件是如果您选择使用它，您应该解释为什么您认为这是一个好主意。根据我的经验，将您的解释放在一起会促使开发人员做出正确的决定。
请注意，架构不是组织中的多个开发人员应该设计的东西（尽管他们可能对流程有输入）。架构最好由一个有才华且经验丰富的个人设计 - 他/她不需要模糊的指导方针。

【解决方案5】：

我会添加单元测试。如果我的开发 PC 在荒岛上只能拥有一件东西，那就是它了。

测试驱动开发的从业者会断言这是他们架构的一个组成部分，因为测试本质上定义了您的应用程序的行为。

【讨论】：

【解决方案6】：

指南没有架构指南怎么办？

除了开玩笑，我认为制定最重要的指导方针是：

让任何系统的架构师积极参与编写实际生产代码的开发团队

恕我直言，这是获得对系统做出架构决策所需的信息级别的唯一方法。它还迫使架构师拥有“游戏中的皮肤”，并产生明显的好处。

【讨论】：

【解决方案7】：

您见过 MS 模式与实践组的 this guideline 吗？他们从应用的角度而不是实践的角度来看待它。

【讨论】：

【解决方案8】：

在我看来，让您的初级开发人员阅读 Code Complete 和 The Pragmatic Programmer。这些高级成语都在这里介绍。

【讨论】：