软件架构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人年,否则不要启动一个。

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

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

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

结论

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

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

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

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

原文发布于微信公众号 - 程序你好(codinghello)

原文发表时间:2018-08-09

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Forrest随想录

从0到1:蘑菇街运维技术管理体系建设分享(上)

大家下午好!我叫赵成,来自蘑菇街。今天给大家分享的题目是从0到1,蘑菇街运维技术管理体系建设分享。正式开始分享之前,首先作一个简单的自我介绍和公司介绍。我叫赵成...

2772
来自专栏技术翻译

2018年ETL工具比较

提取,转换和加载(ETL)工具使组织能够跨不同的数据系统使其数据可访问,有意义且可用。通常,公司在了解尝试编码和构建内部解决方案的成本和复杂性时,首先意识到对E...

1.1K1
来自专栏大数据钻研

十年Web开发技术经验感受

这里列举的后台技术,所有是我工作中所有的要点,并进行了简单的归类,如果你有更好的归类方式,欢迎提出。   我想其中的重点应该还是服务器脚本部分,例如Java,...

37112
来自专栏老安的博客

一个优雅的报警处理系统范例

1893
来自专栏北京马哥教育

史上最全互联网运维工作规划!十分钟找到职业方向!

互联网运维工作,以服务为中心,以稳定、安全、高效为三个基本点,确保公司的互联网业务能够7×24小时为用户提供高质量的服务。 运维人员对公司互联网业务所依赖的基础...

98611
来自专栏追不上乌龟的兔子

七种微服务反模式

流行术语为那些逐步形成的、需要一个好的“标签”来方便交流的概念提供了一个上下文。微服务就是这样的一个新“标签”,它定义了一个领域,这个领域我自己也发现了,并且...

2209
来自专栏京东技术

移动测试避坑指南(第一篇):从流程到技术的知识概要

1964
来自专栏WeTest质量开放平台团队的专栏

手游MOBA之殇在网络——浅析手游网络损伤专项测试

弱网络专项测试(客户端网络损伤专项测试)是腾讯游戏内部评审时,非常重要的一环,直接决定了产品是否能直接上线运营。针对最近非常火爆的MOBA类游戏,对客户端网络损...

1292
来自专栏大数据文摘

Facebook数据被滥用?8个视频案例教你用好Facebook Graph API

1422
来自专栏云计算D1net

微服务架构崛起 能否成为下一代云计算?

IT架构一直从all in one到近两年热门的微服务架构,技术不断进步,微服务架构模式(Microservice Architect Pattern)开始被越...

3765

扫码关注云+社区

领取腾讯云代金券