以同样的方式我们有编码标准，有没有诸如架构标准之类的东西？
这些将是我们可以传递给经验不足的程序员的高级主体，因此当他们开始设计变更或小型应用程序时，他们知道我们期望看到的内容，而没有经验丰富的程序员必须纠正它们（请注意，这不是审查，尽可能早地防止明显的错误。）
我认为它可能包含诸如“始终规范化您的数据库，除非有明确理解不明白的原因”，“始终将表示，逻辑和持久性分开”。
人们是否认为这个级别太高而无法实际应用？或者，鉴于我们可能要求编写的各种功能，这种概括几乎是不可能的？或者它可能有用吗？
如果你认为它们是有用的和现实的，你会包括什么？
（如果它有助于澄清我正在考虑企业风格业务系统的Java / .NET级别编程）。
答案 0 :(得分：3)
SOLID principles将是一个开始的好地方
答案 1 :(得分：3)
我们确实有架构指南。它们被称为design patterns。这些基本上是正式的，您可以酌情遵循的架构指南。
不幸的是，成为真正的软件架构师的一部分是能够决定何时以及如何应用某些模式/指南/实践。这不是必须自动化或直接打印的东西 - 几乎总有不止一种方法可以做某事，每种方式都有成本和收益。这项技能来自于理解这些方面的整个范围，并在前面做出一个好的决定。
答案 2 :(得分：2)
这很难做到这就是为什么通常的做法是让更高级的团队成员处理架构决策和编码。如果让高级团队成员同时做两件事是不切实际的，那么至少让该成员成为设计和审查过程中不可或缺的一部分。
答案 3 :(得分：2)
“始终将演示文稿分开， 逻辑和持久性“。
除非有充分理由不这样做。
对于那些比代码更模糊的架构，这样的规则很快会退化为挥手和退出的条款。所以这样的指导方针是可行的，但我不认为它们会有用。在一天结束时，你依赖于建筑师的专业知识和知识 - 用一半不熟练的规则（以及谁制定这些规则）来哄骗他或她？这似乎不是一个好主意。
答案 4 :(得分：2)
我会将单元测试添加到堆中。如果我在开发PC的沙漠岛上只有一件事，那就是它。
测试驱动开发的从业者将断言这是他们架构中不可或缺的一部分，因为测试基本上定义了应用程序的行为。
答案 5 :(得分：2)
指南没有架构指南？
开玩笑说我认为制定最重要的指导原则是：
让任何系统的架构师积极参与编写实际生产代码的开发团队
恕我直言，这是获得有关系统架构决策所需信息级别的唯一方法。它还迫使建筑师拥有“游戏中的皮肤”，并带来明显的好处。
答案 6 :(得分：2)
你看过MS Pattern＆amp;的this guideline了吗？实践小组？他们从应用程序角度而不是实践角度来看待它。
答案 7 :(得分：1)
在我看来，您的初级开发人员会阅读Code Complete和The Pragmatic Programmer。这些高级习语在这里介绍。