专栏首页程序你好软件架构30条原则

软件架构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)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

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

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

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Tensorflow实现在浏览器的深度学习

    程序你好
  • C# 9.0新特性介绍

    C# 9.0 引入了Record类型,这是一种引用类型,它提供合成方法来提供值语义,从而实现相等性。 默认情况下,记录是不可变的。

    程序你好
  • 深度学习框架机器学习的开源库TensorFlow

    程序你好
  • 《原则》前言

    yeedomliu
  • 设计模式 -- 设计原则

    Define: Software entities like classes,modules and functions should be open for...

    Arbiter
  • 写了这么多年代码,你真的了解SOLID吗?| 洞见

    尽管大家都认为SOLID是非常重要的设计原则,并且对每一条原则都耳熟能详,但我发现大部分开发者并没有真正理解。要获得最大收益,就必须理解它们之间的关系,并综合应...

    ThoughtWorks
  • 一些软件设计的原则

    以前本站向大家介绍过一些软件开发的原则,比如优质代码的十诫和Unix传奇(下篇)中所以说的UNIX的设计原则。相信大家从中能够从中学了解到一些设计原理方面的知识...

    黑光技术
  • Apache架构师总结的30条设计原则!

    今天把 RPC 框架乞丐版差不多写完了(断断续续写了差不多一个月),下周README写完之后就开源出来。

    Guide哥
  • 大话设计模式笔记(三)——单一、开放封闭、依赖倒转、里氏替换四大设计原则

    版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。 ...

    逝兮诚
  • Apache架构师的30条设计原则!

    Srinath 通过不懈的努力最终总结出了30条架构原则,他主张架构师的角色应该由开发团队本身去扮演,而不是专门有个架构师团队或部门。Srinath 认为架构师...

    开源社

扫码关注云+社区

领取腾讯云代金券