软件架构的30条原则

基本原则

原则 1: KISS (Keep it simple, stupid)  “指设计时要坚持简约原则，避免不必要的复杂化。” 其思想是使用最简单的解决方案来完成这项工作。

 

原则 2: YAGNI (You aren’t gonna need it) — 在确定需要之前不要构建它。

 

原则 3: Crawl, walk, run. 换句话说，先让它工作，然后再让它变得更好，最后让它变得伟大。做迭代开发——做敏捷的迭代开发。对于每个特性，创建里程碑(最长2周)并迭代。

 

原则 4: 构建稳定、高质量产品的唯一方法是通过自动化测试。在自动化测试中要有创造性;一切都可以自动化!当你设计的时候想想这个。

 

原则 5: 始终考虑投资回报(ROI)，并将最大的注意力投入到产生最大的影响上。

 

原则 6: 了解您的用户并相应地平衡您的工作。对于大多数产品，将有成千上万的最终用户、20个产品的开发人员和100个DevOp人员来维护。例如，不要花费几个月的时间来为DevOp人员构建一个UI(他们根本不会用UI，相反他们喜欢使用脚本!)。这是原则5的一个特例。

 

原则 7: 尽可能独立地设计和测试特性。当你设计的时候想想这个。从长远来看，它会省去很多麻烦，否则，您无法测试系统，直到所有东西都构建好。而且，有了这个原则，你的发布也会更流畅。

 

原则 8: 我们都喜欢闪亮的设计，但是不要将您永远不需要的特性和解决方案引入到架构中。

可选的

 

原则 9: 要完全考虑用户将如何使用我们的产品是不可能的。所以拥抱MVP(最小可行产品)吧。其思想是找出很少的用例，只做支持这些用例的特性，发布产品，并基于反馈和经验塑造未来的产品。

原则 10: 尽可能少地开发功能;当你不确定的时候，不要去想它。许多功能从未使用过;也许你会留下一个扩展点。

原则 11: 等待别人的要求（特别是对于某些功能，直到确实有必要再进行添加）

原则 12:如果客户要求的功能搞砸了大局，你要有勇气与之斗争。找出更大的图景，试着找到另一种方法来解决这个问题。牢记你是行家，你应该带头。你的工作是做正确的事，而不是受欢迎的事。用户稍后会感谢您。

 

服务器设计和并发性

 

原则 13: 了解服务器如何工作，从硬件到操作系统，直至您的编程语言。优化IO调用的数量是通向最佳架构的第一盏指路明灯。

原则 14: 了解Amdhal的同步定律。线程间共享的可变数据会减慢程序的速度。如果可能的话，使用并发数据结构，并且只有在必要时才使用同步。试着尽可能短的时间锁住锁。如果你打算在锁的时候阻止，确保你知道你在做什么。如果它能坏，它就会坏。

原则 15:如果您的设计是非阻塞的、事件驱动的体系结构，那么永远不要阻塞线程或从这些线程执行IO。如果你这样做了，系统就会像骡子一样慢。

分布式系统

 

原则 16:状态系统是可扩展的和直接的。尽可能了解和使用无共享架构。

原则 17: 除非您同时控制客户端和服务器上的代码，否则即使消息传递失败，也很难一次完成。试着设计你的系统来减少需求(使用原则18)。要知道，大多数承诺一次交货的系统都在某个地方偷工减料。

原则 18: 尽可能实现幂等操作。这样，您就可以轻松恢复，您也可以立即进行一次交付。

原则 19: 知道CAP定理。扩展交易是困难的。在可能的情况下使用补偿。基于rdbms的事务不进行扩展。

原则 20: 分布式共识不会扩展，群组通信也不会，集群范围内的可靠消息传递也不会。任何一个节点的最大限制都是一天大约8个节点。

原则 21: 在分布式系统中，永远不能隐藏延迟和故障(请参阅解释的分布式计算谬论)。

用户体验

 

原则 22: 了解你的用户并了解他们的目标:他是新手、专家还是普通用户?他懂多少计算机科学?极客喜欢扩展点，开发人员喜欢示例和脚本，普通人喜欢ui。

原则 23: 最好的产品不需要说明书。它的使用是不言自明的。

原则 24:当您无法在两种选择之间做出选择时，不要将问题作为配置选项传递。您让用户和解决方案架构师的日子不好过。如果他们比你更不了解这个系统是如何工作的，他们怎么能做出决定呢?最好的选择是找到一个每次都有效的选择;其次是自动进行选择，第三是添加配置参数并设置合理的默认值。

原则 25: 对于配置总是有合理的默认值。

原则 26:设计不良的配置可能会造成很多混乱。总是记录一些配置的示例值。

原则 27: 根据用户不需要计算就能回答的问题来询问配置值(例如，不要询问最大缓存条目的数量——而是询问应该用于缓存的最大内存数量)

原则 28: 如果看到未知的配置，就抛出错误。永远默默地忽略它。无声的配置错误是调试过程中许多时间丢失的根源。

面临的困难

 

原则 29: 构思一门新语言很容易，但要把它弄好却很难。尽量不要这样做，除非团队可以在这上面花费至少10人年的时间。如果你仍然不确定，请阅读关于语言设计的五个问题。

原则 30: 可组合的拖放ui很困难，除非团队准备在其中投入10人年，否则不要启动一个。

最后，让我谈谈一件随着时间的推移而改变了主意的事情。在理想的情况下，平台必须由正交组件组成——每个组件处理一个方面(例如，安全性、消息传递、注册表、中介、分析)。具有这些特性的系统将是最理想的。

 

不幸的是，很难实现那种状态。严格执行这一点可能是错误的，有时我们发现我们添加的特性根本没用，然后所有额外的工作都白白地浪费掉了。最后，如果这导致了多个团队之间的协商，那么这个特性可能永远无法完成。

 

现在回过头来看，当我试图消除复制导致的显著复杂性时，我愿意忍受重复。治愈可能比疾病更糟糕。

 

结论

 

作为架构师，一个人应该像一个园丁一样思考，他塑造、管理和清除杂草，而不是定义和建造。你应该策划而不是命令，塑造而不是定义，煽动讨论而不是贴上标签。

 

虽然在短期内支配体系结构可能更便宜、更容易，但从长期来看，指导和让团队找到他们的方法是有好处的。

 

如果你不小心，那么你就更容易从架构出发，因为设计师只告诉你他的架构是错误的，而不告诉你为什么是错误的。避免这种情况的一种方法是制定一套被广泛接受的原则，这些原则将成为未来建筑师讨论和学习的基础。

 

我们讨论了一些帮助我应对挑战的原则。下面是总结。