中生代技术 程序员突破成长的好伙伴每天8点推送有营养的文章

正文共：3684字

预计阅读时间：5分钟

【CSDN编者按】众所周知，架构师的角色，更偏向于策划、而非指挥，塑造、而非支配，其存在的意义，在于引导大家讨论、而非自己主宰一切。

但是，具体应该如何执行呢？本文作者整理了 30 个公认的架构原则，来帮助大家解决此问题。也许有的原则，你从未听说，但你看完就能快速学会。

相信你学会了，工作起来也会事半功倍，或许还可帮你避免很多无用的加班！

想一下软件架构的评审过程：一位架构师参与进来，俯视一切然后指指点点，高谈阔论。他发表的评论要么过于粗浅，要么严重脱离实际。

大家对其意见要么极度沉默，要么强烈反对。这对团队几乎没有任何帮助。程序员和架构师都对这样的架构评审望而生畏。

软件架构师的角色应当像园丁而非指挥官。前者的职责主要是塑造、策划并清除杂草，而后者主要任务是发号施令。

在 WSO2，我参与架构评审的时间已长达八年之久。WSO2 的产品非常丰富，比如 WSO2 ESB 、WSO2 API Manager  以及 WSO2 SP  都人尽皆知。在过去八年中，我们对许多产品和功能进行了讨论、设计、改进和重新设计。

我们在设计软件的过程中，把握的一个关键点是：软件架构并非由架构师负责设计。我们的架构不是由架构师制定，然后交给其他人来实施。

相反，架构的设计任务由真正编写代码的团队负责。架构师负责对工程师设计的架构进行修复、策划和改进。我们的架构团队是指导员和把关人，而非独裁者。

在短期内，由一位架构师来制定架构的确既快捷又实惠。但是，从长远来看，我们会组建一个团队，让他们自己不断思考、改善架构，并从他们的错误中来提升自己。

当我们专注于团队时，他们自然会随着时间的推移而变得更好。架构团队的首要任务是：尽可能保证架构容易执行。

此外，架构评审也存在缺陷。就像 Paul （@pzfreo）描述的架构评审那样：架构师参与进来，听一会，发表一点评论然后就走了。

作为一名架构师，你对架构发表自己的看法和意见无可厚非。但是，如果你不够投入和细心，你的意见可能会让团队感到困惑，团队就无法确定正确的做法到底是什么。

接下来我会将30个架构原则一一列出，其中一些原则是众所周知的，而有些则源于我的个人经验和心血。

基本原则

原则1： KISS（Keep it simple 保持简单）原则 ，尽可能让一切变得简单。该原则鼓励我们用最简单的解决方案来完成工作。

原则2：YAGNI（You aren't gonna need it 你不需要它）原则 ，只在需要时构建。

原则3：先学会爬，然后再学会走，最后学会跑。换句话说，先保证能够正常运行，然后优化它使其更好，最后逐渐让它变得完美。使用迭代开发，采用敏捷开发模式。为每个功能制定一个开发周期（最多2周），然后不断迭代。

原则4：自动化测试是构建稳定、高质量产品的唯一方法。通过自动化测试提升创造力，所有一切都可以自动化!在设计时应当好好考虑自动化。

原则5：注重投资回报率Return of Investment（ROI）并将最多的注意力放在最重要的地方。

原则6：了解用户并相应地平衡资源。大多数产品都有数千个最终用户，大致需要20个开发人员和100个 DevOp 人员。不要花费数月的时间来构建一个不太可能使用 DevOp 的用户界面（他们更喜欢脚本！）。这是原则5的特例。

原则7：功能的设计和测试尽可能独立。如果在设计时考虑到这一点，长远来看，它将省去很多麻烦，否则只有一切构建完成时你才可以开始测试整个系统。此外，遵循这个原则，版本发布也会更加顺利。

原则8：警惕搜索引擎中花里胡哨的架构方案。我们天生都喜欢令人夺目的设计。如果你按捺不住， 就可能把太多根本不需要的功能和解决方案引入到你的架构中。

选择功能

原则9：想要准确知道用户如何使用我们的产品是很难的。所以我们要推行MVP（最小可行产品）。该理念的核心在于：先制定一些用例，完成用例所涉及的相关功能，立即发布产品，然后根据反馈和经验对产品进行优化。

原则10：尽可能减少功能，如有疑问则将其删除。许多功能可能从未使用，你只需为其留一个扩展接口即可。

原则11：听取客户的意见，看他们想要什么功能。

原则12：当客户要求的功能影响到其他模块时，要勇于和客户辩论。从大局出发，尝试找到另一种方法来处理问题。就像 Fords 所说的那样“每当我问顾客需要什么的时候,他们总是会说需要跑得更快的马”。请记住，你才是专家。你应该主导一切，做出正确和专业的决定。虽然用户可能当时有些疑惑，但最终他们会感谢你的。

服务器设计与并发

原则13：从硬件、操作系统到你使用的编程语言等多方面深入了解服务器的工作原理。优化 IO 操作的效率是一个良好架构的首要任务。

原则14：遵循 Amdhal 的同步定律。线程之间共享的可变数据会降低程序速度。如果可以，请使用并发数据结构，并且仅在必要时使用同步。尽可能少地使用锁。如果你打算在线程锁期间阻塞，请确保自己足够了解具体细节，因为这里存在极大的隐患。

原则15：如果你的设计是基于事件驱动的非阻塞架构，那就不要阻塞线程或者在线程中执行 IO 操作。一旦这样做，系统将慢如蜗牛。

分布式系统

原则16：无状态系统具有良好的扩展性。我们要尽可能了解和使用无分享架构。

原则17：除非你能够掌控客户端和服务器的所有代码，否则消息传递失败的情况在所难免。尽量减少你的系统依赖的因素（例如使用原则18）。

原则18：尽可能实施幂等操作。这样它就很容易恢复，你至少可以保证交付没问题。

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

原则20：分布式系统共识不支持扩展，也无法进行组通信，不支持群集范围内的可靠消息传递。其最大节点限制大约是八个节点。

原则21：你很难隐藏分布式系统中的延迟和故障。（参见分布式计算的谬误解释 ）。

用户体验

原则22：了解你的用户以及他们的目标：他是新手、专家还是临时用户？他对计算机科学了解多少？极客看重扩展功能，开发人员关注示例和脚本，普通人则更在乎界面。

原则23：最好的产品应当不需要用户手册，用户应该一看就会用。

原则24：当你无法在两个选项之间做出决定时，请不要通过配置选项的方式来呈现问题。这会给用户和架构师带来麻烦。对于系统如何运作的细节，他们没有你了解，他们怎么能做出决定呢？最好的方案是找到一个每次都有效的选择；其次是自动做出选择；第三个方案是添加配置参数并设置合理的默认值。

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

原则26：设计不良的配置会制造麻烦。始终配置几个示例值。

原则27：询问用户配置值的时候，注意选择用户无需即可设置的值（例如，不要问用户需要的最大缓存条目数量，而是要问他想要用于缓存的内存数量）

原则28：如果发现未知配置，则抛出错误。永远不要忽视它。在调试过程中，无提示的配置错误会浪费我们很多调试时间。

难点

原则29：尝试新语言很容易，但要正确使用却很难。除非公司愿意组建一个十人团队并花一年的时间来学习，否则尽量不要这样做。如果你仍不死心，请阅读有关语言设计的五个问题 后再做定夺。

原则30：可组合的拖放 UI 很难实现，除非团队准备投入10人年的资源，否则不要去做。

最后，让我谈一些随着时间的推移我的主意发生变化的事情。在理想情况下，一个平台应当由多个组件组成，每个组件负责一个方面（例如，安全性、消息传递、注册、调解、分析，等等）。使用这些功能构建的系统将是最佳的。

不幸的是，严格执行这一点可能是一个错误，特别是在新功能的初始状态，其中简单的功能可能导致大的变化，因为我们试图使一切都是垂直的。有时我们发现我们添加的功能没用，然后所有额外的工作都没有用。最后，如果这需要多个团队之间的协商，该功能可能永远都无法完成。

现在来看，我愿意接受重复。治疗带来的结果可能会比疾病导致后果更严重。

结论

作为架构师，我们应该像园丁一样思考、塑造、策划和去除杂草而不是定义和构建。

在短期内，由一位架构师来制定架构的确既快捷又实惠。但是，从长远来看，团队的力量才是最强的。

如果你不够投入和细心，你只指出错误，但是不道明错误原因，那么你的意见可能会让团队感到困惑。避免这种情况的一种方法是拥有一套普遍接受的原则，这些原则是讨论架构时遵循的基本点，也是初学者学习架构的好资源。

原文：https://hackernoon.com/first-do-no-harm-30-principles-that-helped-me-avoid-fly-by-architecture-reviews-e8952ac632a

作者：Srinath Perera ，是一位计算机科学家、软件架构师、作家，他是 apache 的核心成员，拥有 15 年分布式系统编程经验，设计了 Apache Axis2 以及 WSO2 流处理器。

译者：安翔，责编：胡巍巍

架构师好文回顾

☞ 牛逼的架构师是怎么炼成的？

☞ 李艳鹏：史上最全的架构师图谱

☞ 架构师，是否需要写代码

☞ 架构大咖言传身教：从程序员到架构师

☞ 听说过全栈工程师，那全栈架构师又是什么鬼？

#专注技术人的成长#