是否可能有架构指导方针?如果是这样的话,里面应该有什么?

这个 SOLID principles 会是一个很好的开始的地方

我们确实有体系结构指南。它们叫 design patterns . 这些基本上是形式化的体系结构指导原则,您可以根据需要遵循这些指导原则。

不幸的是,成为真正的软件架构师的一部分是能够决定何时以及如何应用某些模式/指导方针/实践。这不一定是可以直接自动化或打印的东西——几乎总是有不止一种方法可以做到这一点,而且每一种方法都有成本和收益。这项技能包括了解所有这些方面,并提前做出一个好的决定。

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

“始终将演示文稿分开, 逻辑与坚持”。

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

对于比代码更模糊的体系结构,这样的规则很快就会退化为手舞足蹈的子句。所以这样的指导方针是可能的,但我不认为它们是有用的。一天结束的时候,你依靠的是建筑师的专业知识和知识——用半生不熟的规则让他或她步履蹒跚(谁制定了这些规则?)似乎不是个好主意。

我会补充 单元测试 到桩上。如果用我的开发PC在荒岛上只有一件东西,那就是它了。

测试驱动开发的实践者将断言这是他们体系结构的一个组成部分,因为测试基本上定义了应用程序的行为。

指南没有体系结构指南呢?

开玩笑吧,我认为最重要的指导方针是:

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

imho,这是获得系统架构决策所需信息级别的唯一方法。它还迫使架构师拥有“游戏中的皮肤”,并带来明显的好处。

你见过吗? this guideline 来自MS Pattern&Practices Group?他们从应用的角度而不是实践的角度来看待它。

在我看来,让你的初级开发人员阅读完整的代码和实用的程序员。这里介绍了这些高级习语。