软件架构原则

软件架构设计原则


基本原则

原则1: KISS (Keep it simple,sutpid) 和保持每件事情都尽可能的简单,用最简单的解决方案来解决问题。

原则2: YAGNI(你不需要它)原则 ,只在需要时构建

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

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

原则5: 注重投资回报率(ROI)并将最多的注意力放在最重要的地方。

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

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

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


功能选择

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

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

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

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


服务端设计和并发

原则13: 要知道一个server是如何运行的,从硬件到操作系统,直到编程语言。优化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人年的资源,否则不要去做。


原文地址 架构设计的30条设计原则

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章