讨论软件架构的30个共同原则

想象一下飞越架构评论。一位建筑师走进来，看着，通过他的双筒望远镜凝视着他。他提供的评论通常过于通用或脱离背景。评论经常遭到震耳欲聋的沉默或激动人心的争论。如果有的话，他们很少帮助任何人。每个程序员都害怕它; 每个建筑师也都害怕它。

据说，作为软件架构师，人们应该像园丁一样思考而不是指挥官。前者塑造，策划并去除杂草，而后者定义和指示。建筑师应该策划而不是指挥，塑造而不是定义，并煽动讨论而不是标签。但是，如何让它发挥作用？

在WSO2，我已经完成了八年多的架构评审。WSO2拥有广泛的产品组合，包括众所周知的WSO2 ESB，WSO2 API Manager和WSO2 SP。在过去的八年中，我们对许多产品和功能进行了辩论，设计，改进和重新设计。

我们设计过程的一个关键部分是架构不是由架构师完成的。我们没有一组建筑师负责管理架构蓝图，而其他人则去实施它。相反，设计由编写代码的团队完成。建筑师修复，抱怨，策划和改进设计。我们有一个建筑团队，但他们是导游和守门人，而不是独裁者。

Gregor Hohpe在这次演讲中精美地捕捉到了这个想法。

是真的。在短期内，规定架构更快，甚至可能更便宜。但是，从长远来看，我们通过让他们自己思考，让他们发展架构，有时让他们犯错误来建立更好的团队。当我们专注于团队时，他们会随着时间的推移而变得更好。执行起来要容易得多，因为架构首先是团队的想法。

然而，建筑评论也存在缺陷。保罗（@pzfreo）过去常常通过建筑师来称呼这个驱动器，其中建筑师走进来，倾听，发表评论并继续前进。作为一名建筑师，它更容易看起来，抱怨并将设计分开。如果你不小心，你可能会让团队感到困惑，不确定什么是正确的做法。

我们通过列出共享体系结构主体来解决此问题。这些是每个人都同意的原则。建筑师提出反馈说，由于校长X，这是不好的。原则指导我们并使我们的讨论根深蒂固。他们还避免了永远持续的哲学战争。最后，如果设计师从未听说过这个原理，那么他很容易学习。

以下是其中一些原则。有些是众所周知的，而有些则是我们选择的方式。

基本

原则1： KISS（保持简单，愚蠢）和“一切尽可能简单，但不简单。”这个想法是使用最简单的解决方案来完成工作。

原则2：YAGNI（你不需要它） -在需要之前不要构建它。

原则3：爬行，走路，跑步。换句话说，让它发挥作用，让它更好，让它变得更好。迭代开发 - 做敏捷，迭代开发。对于每个功能，创建里程碑（最多2周）并迭代。

原则4：构建稳定，高质量产品的唯一方法是通过自动化测试。通过自动化测试发挥创意; 一切都可以自动化！在设计时考虑一下。

原则5：始终考虑投资回报率（ROI）并将最多的注意力放在产生最大影响上。

原则6：了解您的用户并相应地平衡您的努力。对于大多数产品，将有数千个最终用户，20个扩展产品的开发人员和100个设置它的DevOp个人。例如，不要花费数月的时间来构建一个不太可能使用它的DevOp用户界面（他们喜欢脚本！）。这是原则5的特例。

原则7：尽可能独立地设计和测试功能。在设计时考虑一下。从长远来看，它将节省很多麻烦，否则，在构建所有内容之前，您无法测试系统。此外，根据这一原则，您的版本将更加顺畅。

原则8：留意“谷歌嫉妒”。我们都喜欢闪亮的设计。您可以轻松地将功能和解决方案引入您永远不需要的架构中。

选择功能

原则9：不可能充分考虑用户如何使用我们的产品。所以拥抱MVP（最小可行产品）。我们的想法是找出一些用例，只做一些支持这些用例的功能，运送产品，并根据反馈和经验塑造未来的产品。

原则10：尽可能少的功能; 如有疑问，请将其删除。许多功能从未使用过; 也许你会留下一个扩展点。

原则11：等待有人要求（例如，对于不是交易破坏者的功能，请等到需要它）。

原则12：如果他要求弄乱大局，有勇气与客户作斗争。找出更大的图片，并尝试找到另一种方法来处理问题。请记住亨利福特的话：“如果我问过人们他们想要什么，他们就会说'马更快。'”而且，请记住你是专家。你应该领导。做正确的事情是领导者的工作，而不是流行的事情。用户以后会感谢你。

服务器设计和并发

原则13：了解服务器的工作方式，从硬件到操作系统，再到编程语言。优化IO调用的数量是迈向最佳架构的第一指导。

原则14：了解Amdhal关于同步的定律。线程之间共享的可变数据会降低程序的速度。如果可以，请使用并发数据结构，并且仅在必要时使用同步。尝试尽可能少地抓住锁。如果您计划在持有锁定时阻止，请确保您知道自己在做什么。如果它可以破坏，它会。

原则15：如果您的设计是非阻塞的事件驱动架构，则永远不要阻塞线程或从这些线程执行IO。如果这样做，系统将像骡子一样慢。

分布式系统

原则16：无状态系统具有可扩展性和直接性。尽可能了解并使用Shared Nothing Architecture。

原则17：除非您在客户端和服务器中都控制代码，否则完全一旦消息传递，无论失败，都很难。尝试将您的系统设计得更少（使用原则18）。知道大多数承诺一次交付的系统会在某个地方偷工减料。

原则18：尽可能将操作实施为幂等操作。然后它很容易恢复，你可以至少一次交付。

原则19：了解CAP定理。扩展交易很难。尽可能使用补偿。基于RDBMS的事务不会扩展。

原则20：分布式共识不扩展，也不进行组通信，也不进行群集范围内的可靠消息传递。在一个美好的一天中，任一个的最大节点限制大约是八个节点。

原则21：您永远不能隐藏分布式系统中的延迟和故障（请参阅分布式计算的谬误解释）。

用户体验

原则22：了解您的用户并了解他们的目标：他是新手，专家还是临时用户？他对计算机科学了解多少？极客喜欢扩展点，像样本和脚本的开发人员，像UI这样的普通人。

原则23： 最好的产品不需要手册。它的用途是不言而喻的。

原则24：如果您无法在两个选项之间做出决定，请不要通过将其作为配置选项来传递问题。您正在为用户和解决方案架构师努力工作。如果他们对系统的工作方式了解甚少，那么他们又如何决定呢？最好的选择是找到一个每次都有效的选择; 下一个最好的是自动做出选择，第三个最好是添加配置参数并设置合理的默认值。

原则25：始终具有合理的配置默认值。

原则26：设计不良的配置会造成很多混乱。始终记录配置的一些示例值。

原则27：根据用户可以回答的问题配置值，而无需计算设置值（例如，不要求最大缓存条目的数量 - 而是要求最大内存应该用于缓存）

原则28：如果看到未知配置，则抛出错误。永远不要忽视它。调试时，无提示配置错误是许多丢失时间的来源。

难题

原则29：梦想新语言很容易，但要做到正确是非常困难的。除非团队可以花费至少十个人年，否则尽量不要这样做。如果您仍然不确定，请阅读有关语言设计的五个问题。

原则30：可组合的拖放UI很难，除非团队准备投入10个人年，否则不要启动。

最后，让我谈谈我随着时间的推移改变主意的事情。在理想的世界中，平台必须由正交组件组成 - 每个组件处理一个方面（例如，安全性，消息传递，注册，调解，分析）。使用这些功能构建的系统将是最佳的。

不幸的是，很难到达那个州。它很难留在那里。严格执行这一点可能是一个错误，特别是在新功能的初始状态，其中简单的功能可以级联到大的变化，因为我们试图使一切正交。有时我们发现我们添加的功能毕竟没用，然后所有额外的工作都没有用。最后，如果这导致多个团队之间的协商，该功能可能永远不会完成。

事后来看，现在我愿意在尝试删除它时带来重复，导致重大的复杂性。治愈可能比疾病更糟。

结论

作为建筑师，人们应该像园丁一样思考，塑造，策划和清除杂草，而不是定义和建造。你应该策划而不是指挥，塑造而不是定义，并煽动讨论而不是标签。 虽然短期内可能会更便宜，更容易决定架构，但从长远来看，指导并让团队找到自己的方式会带来好处。

如果你不小心，建筑飞行更容易，设计师只告诉他的架构是错误的，但不是为什么它是错的。避免这种情况的一种方法是拥有一套普遍接受的原则，这些原则成为讨论的锚点，也是新兴建筑师的学习路径。

原文标题《30 Shared Principles for Discussing Software Architectures》

作者：Srinath Perera

译者：February

不代表云加社区观点，更多详情请查看原文链接