成为优秀架构师必须了解的30条设计原则但是应该如何实施呢？本文作者整理了30条公认的架构原则来帮助你解决这个问题。可能有些原理你没听过，但是看完之后你很快就能学会。相信学了会事半功倍，说不定还能避免很多无用的加班呢！本文作者是计算机科学家、软件架构师和作家SrinathPerera。Apache核心成员，拥有15年分布式系统编程经验，设计过ApacheAxis2和WSO2流处理器。在WSO2，我已经参与架构审查八年了。WSO2的产品非常丰富，众所周知的有WSO2ESB、WSO2APIManager、WSO2SP。在过去的八年中，许多产品和功能已经过讨论、设计、改进和重新设计。在设计软件的过程中，我们抓住了一个关键点：软件架构不是架构师设计的。我们的架构不是由架构师编写并交给其他人实施的。相反，设计架构的任务落到了实际编写代码的团队身上。架构师负责修复、改进和改进工程师设计的架构。我们的架构团队是向导和看门人，而不是独裁者。从短期来看，让架构师开发架构确实既快捷又便宜。但是，从长远来看，我们建立了一个不断独立思考、改进架构并从错误中吸取教训的团队。当我们专注于团队时，他们自然会随着时间的推移变得更好。架构团队的首要任务是使架构尽可能易于执行。此外，架构审查存在缺陷。这就像Paul(@pzfreo)描述的架构审查：架构师进来，倾听，发表一些评论然后走开。作为一名建筑师，表达你对建筑的看法和意见并没有错。但是，如果您不够坚定和谨慎，您的评论可能会使团队感到困惑，并且团队将无法确定正确的行动方案。接下来，我将一一列出30条架构原则，其中一些是众所周知的，而一些是我个人的经验和努力得来的。基本原则原则一：KISS（Keepitsimple,sutpid），让一切尽可能简单，用最简单的方案解决问题。原则二：YAGNI（YouDon'tNeedIt）原则，只在需要时构建。原则三：先学爬，再学走，最后学跑。换句话说，确保它可以工作，然后优化它使其更好，然后逐渐使其完善。使用迭代开发，采用敏捷开发模式。为每个功能创建一个开发周期（最多2周）并进行迭代。原则4：自动化测试是构建稳定、高质量产品的唯一途径。通过自动化测试提升创造力，一切都可以自动化！设计时考虑自动化。原则5：关注投资回报率(ROI)，并将最多注意力放在最重要的地方。原则6：了解您的用户并相应地平衡资源。大多数产品都有成千上万的最终用户、大约20名开发人员和100名DevOps人员。不要花费数月时间构建不太可能使用DevOps的用户界面（他们更喜欢脚本）。这是原则5的特例。原则7：尽可能独立地设计和测试功能。如果你设计时考虑到这一点，从长远来看，它会为你省去很多麻烦，否则你只能在所有东西都构建好后才能开始测试整个系统。另外，遵循这个原则，版本发布会更顺畅。原则8：警惕搜索引擎架构中的附加功能。我们天生都喜欢引人注目的设计。如果你忍不住，就会冒着在你的架构中引入太多不需要的特性和解决方案的风险。功能选择原则9：很难准确了解用户如何使用我们的产品。所以我们要实现MVP（MinimumViableProduct）。其理念的核心是：先制定一些用例，完成用例涉及的相关功能，立即发布产品，然后根据反馈和体验对产品进行优化。原则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人/年的资源，否则不要这样做。最后说说我的感受吧。理想情况下，一个平台应该由多个正交组件组成，每个组件负责一个方面（例如，安全、消息传递、注册、调解、分析等）。使用这些功能构建的系统会很好。遗憾的是，在现实中，我们很难达到这样的境界。因为在项目的初始状态，很多东西都是不确定的，你无法做到这样的独立，现在我觉得有必要在开始的时候适当的重复一遍，当你尝试去根除它们的时候，你会发现引入了新的复杂性，分布本身就意味着复杂性。有时愈合过程比疾病本身更糟糕。总结作为一名建筑师，我们应该像园丁一样思考、塑造、策划和除草，而不是定义和建造。虽然在短期内，让架构师来开发架构确实是又快又便宜。但是，从长远来看，强大的还是团队的实力。如果你不够投入和细心，而且你只指出错误，而不是原因，你的评论会让团队感到困惑。避免这种情况的一种方法是有一套普遍接受的原则，这是讨论架构时要遵循的基本要点，也是初学者学习架构的好资源。所以，想要成为一名优秀的架构师，还是需要长期的磨练和时间的验证。当然，随时保持学习也很重要。随着你学到更多的知识，你将能够更清晰地解决各种复杂的架构问题。
