30条设计原则：之物极必反
Apache的架构师们遵循的30条设计原则
本文作者叫Srinath，是一位科学家，软件架构师，也是一名在分布式系统上工作的程序员。 他是Apache Axis2项目的联合创始人，也是Apache Software基金会的成员。 他是WSO2流处理器（wso2.com/analytics）的联席架构师。 Srinath撰写了两本关于MapReduce和许多技术文章的书。 他获得了博士学位。 来自美国印第安纳大学。
Srinath通过不懈的努力最终总结出了30条架构原则，他主张架构师的角色应该由开发团队本身去扮演，而不是专门有个架构师团队或部门。Srinath认为架构师应该扮演的角色是一个引导者，讨论发起者，花草修建者，而不是定义者和构建者。Srinath为了解决团队内部的架构纷争和抉择，制定了以下30条原则，这些原则被成员们广泛认可，也成为了新手架构师的学习途径。
| -- 基本原则 -- | |
| 原则1：KISS(Keep it simple,sutpid) 和保持每件事情都尽可能的简单。用最简单的解决方案来解决问题。 | 必要的简单，而不是尽可能简单 |
| 原则2：YAGNI(You aren’t gonna need it)-不要去搞一些不需要的东西，需要的时候再搞吧。 | 粗略的规划还是要有 |
| 原则3：爬，走，跑。换句话说就是先保证跑通，然后再优化变得更好，然后继续优化让其变得伟大。迭代着去做事情，敏捷开发的思路。对于每个功能点，创建里程碑（最大两周），然后去迭代。 | 同意 |
| 原则4：创建稳定、高质量的产品的唯一方法就是自动化测试。所有的都可以自动化，当你设计时，不妨想想这一点。 | 自动化固然好，人工也不是一无是处。有的的程序完整的测试用例相当难。 |
| 原则5：时刻要想投入产出比（ROI）。就是划得来不。 | 基础研发，有时不得不放弃产出比。因为你对更长期的产出有信心，并且目前尚可维持。 |
| 原则6：了解你的用户，然后基于此来平衡你需要做哪些事情。不要花了几个月时间做了一个devops用户界面，最后你发现那些人只喜欢命令行。此原则是原则5的一个具体表现。 | 有的项目，了解自己，就是了解用户。参见福特造汽车。 |
| 原则7：设计和测试一个功能得尽可能的独立。当你做设计时，应该想想这一条。从长远来看这能给你解决很多问题，否则你的功能只能等待系统其他所有的功能都就绪了才能测试，这显然很不好。有了这个原则， 你的版本将会更加的顺畅。 | 基本同意。这是模块定义的初衷，但也有不合理的地方和不合理时候。就如油画和水墨画的差别，这是unix的编程艺术。 |
| 原则8：不要搞花哨的。我们都喜欢高端炫酷的设计。最后我们搞了很多功能和解决方案到我们的架构中，然后这些东西根本不会被用到。 | 工程师的思维 |
| -- 功能选择 -- | |
| 原则9：不可能预测到用户将会如何使用我们的产品。所以要拥抱MVP（Minimal Viable Product），最小可运行版本。这个观点主要思想就是你挑几个很少的使用场景，然后把它搞出来，然后发布上线让用户使用，然后基于体验和用户反馈再决定下一步要做什么。 | 非常好 |
| 原则10：尽可能的做较少的功能。当有疑问的时候，就不要去做，甚至干掉。很多功能从来不会被使用。最多留个扩展点就够了。 | 以小见大随很好 ，以多见少亦可为 |
| 原则11：等到有人提出再说（除非是影响核心流程，否则就等到需要的时候再去做）。 | 工程师思维 |
| 原则12：有时候你要有勇气和客户说不。这时候你需要找到一个更好的解决方案来去解决。记住亨利福特曾经说过的 ：”如果我问人们他们需要什么，他们会说我需要一匹速度更快的马”。记住：你是那个专家，你要去引导和领导。要去做正确的事情，而不是流行的事情。最终用户会感谢你为他们提供了汽车。 | 设计师思维 |
| -- 服务端设计和并发 -- | |
|
原则13：要知道一个server是如何运行的，从硬件到操作系统，直到编程语言。优化IO调用的数量是你通往最好架构的首选之路。 |
系统软件的运行机制和原理：《程序员的自我修养--链接、装载、与库》 |
| 原则14：要了解Amdhal同步定律。在线程之间共享可变数据会让你的程序变慢。只在必要的时候才去使用并发的数据结构，只在必须使用同步（synchronization）的时候才去使用同步。如果要用锁，也要确保尽可能少的时间去hold住锁。如果要在加锁后做一些事情，要确保自己在锁内会做哪些事情。 |
程序的构造和解释：SICP:《Structure and Interpretation of Computer Programs》 结构化方法：SCO:《Structured Computer Organization》 逻辑及设计基础：LCDF:《Logic and Computer Design Fundamental》 |
| 原则15：如果你的设计是一个无阻塞且事件驱动的架构，那么千万不要阻塞线程或者在这些线程中做一些IO操作，如果你做了，你的系统会慢的像骡子一样。 | 回到算法：TAOCP:《The Art of Computer Programming》 |
| -- 分布式系统 -- | |
|
原则16：无状态的系统的是可扩展的和直接的。任何时候都要考虑这一点，不要搞个不可扩展的，有状态的东东出来，这是起码的。 |
无状态的系统的是可扩展的和直接的。 |
| 原则17：保证消息只被传递一次，不管失败，这很难，除非你要在客户端和服务端都做控制。试着让你的系统更轻便（使用原则18）。你要知道大部分的承诺exactly-once-delivery的系统都是做了精简的。 | OS/DB/Compiler之外，网络也是那么重要。没有网络协议就没有github。 |
| 原则18：实现一个操作尽可能的幂等。这样的话就比较好恢复，而且你还处于至少一次传递（at least once delivery）的状态。 | at least once delivery |
| 原则19：知道CAP理论。可扩展的事务（分布式事务）是很难的。如果可能的的话，尽可能的使用补偿机制。RDBMS事务是无法扩展的。 | 可扩展的事务（分布式事务）是很难的。 |
| 原则20：分布式一致性无法扩展，也无法进行组通信，也无法进行集群范围内的可靠通信。理想情况下最大的节点限制为8个节点。 | 理想情况下最大的节点限制为8个节点。 |
| 原则21：在分布式系统中，你永远无法避免延迟和失败。 | |
| -- 用户体验 -- | |
|
原则22：要了解你的用户和清楚他们的目标。他们是新手、专家还是偶然的用户？他们了解计算机科学的程度。极客喜欢扩展点，开发者喜欢示例和脚本，而普通人则喜欢UI。 |
极客喜欢扩展点，开发者喜欢示例和脚本，而普通人则喜欢UI。 |
| 原则23：最好的产品是不需要产品手册的。 | 同意 |
| 原则24：当你无法在两个选择中做决定的时候，请不要直接把这个问题通过提供配置选项的方式传递给用户。这样只能让用户更加的发懵。如果连你这个专家都无法选择的情况下，交给一个比你了解的还少的人这样合适吗？最好的做法的是每次都找到一个可行的选项；次好的做法是自动的给出选项，第三好的做法是增加一个配置参数，然后设置一个合理的默认值。 | |
| 原则25：总是要为配置设置一个合理的默认值。 | |
| 原则26：设计不良的配置会造成一些困扰。应该总是为配置提供一些示例值。 | |
| 原则27：配置值必须是用户能够理解和直接填写的。比如：不能让用户填写最大缓存条目的数量，而是应该让用户填写可被用于缓存的最大内存。 | |
| 原则28：如果输入了未知的配置要抛出错误。永远不要悄悄的忽略。悄悄的忽略配置错误往往是找bug花了数小时的罪魁祸首。 | |
| -- 艰难的问题 -- | |
|
原则29：梦想着新的编程语言就会变得简单和明了，但往往要想真正掌握会很难。不要轻易的去换编程语言。 |
如果方言是随弃的呢 |
| 原则30：复杂的拖拉拽的界面是艰难的，不要去尝试这样的效果，除非你准备好了10人年的团队。 | No silver bullet. |
最后，说一个我的感受。在一个理想的世界里，一个平台应该是有多个正交组件组成-每个组件都负责一个方面（比如，security，messaging，registry，mdidation，analytics）。好像一个系统构建成这样才是完美的。但不幸的是，现实中我们很难达到这样的状态。因为在项目初始状态时，很多事情是不确定的，你无法做到这样的独立性，现在我更倾向于在开始的时候适当的重复是必要的，当你尝试铲除他们的时候，你会发现引入了新的复杂性，分布本身就意味着复杂。有时候治愈的过程要比疾病本身更加的糟糕。
总结
作为一个架构师，应该像园丁一般，更多的是修剪花草，除草而不是去定义和构建，你应该策划而不是指挥，你应该去修剪而不是去定义，应该是讨论而不是贴标签。虽然在短期内可能会觉得也没什么，但从长远看，指导团队找到自己的方式会带来好处。如果你稍不留神，就很容易让架构成为一个空洞的词汇。比如设计者会说他的架构是错误的，但不知道为什么是错误的。一个避免这种情况的好办法就是有一个原则列表，这个原则列表是被广泛接受的，这个列表是人们讨论问题的锚点，也是新手架构师学习的路径。
30条设计原则：之物极必反相关推荐
- Apache 的架构师们遵循的 30 条设计原则
目录 Apache 的架构师们遵循的 30 条设计原则 基本原则
- Apache架构师的30条设计原则！
点击上方"方志朋",选择"设为星标" 做积极的人,而不是积极废人 作者:Srinath 来源:ImportSource 本文作者叫 Srinath,是一位科学家 ...
- Apache的架构师们遵循的30条设计原则
点击蓝色"程序猿DD"关注我 回复"资源"获取独家整理的学习资料! 来源:ImportSource 本文作者叫Srinath,是一位科学家,软件架构师,也是一名 ...
- Srinath总结 架构师们遵循的 30 条设计原则
作者:Srinath 翻译:贺卓凡,来源:公众号 ImportSource Srinath 通过不懈的努力最终总结出了 30 条架构原则,他主张架构师的角色应该由开发团队本身去扮演,而不是专门有个架构 ...
- Apache架构师总结的30条设计原则！
点击上方"朱小厮的博客",选择"设为星标" 后台回复"加群",加入新技术 Srinath|ImportSource 今天把 RPC 框架乞丐 ...
- 架构师们遵循的30条设计原则
阅读文本大概需要8分钟. Srinath通过不懈的努力最终总结出了30条架构原则,他主张架构师的角色应该由开发团队本身去扮演,而不是专门有个架构师团队或部门.Srinath认为架构师应该扮演的角色是一 ...
- Apache 架构师总结的 30 条架构原则
本文作者叫 Srinath,是一位科学家,软件架构师,也是一名在分布式系统上工作的程序员.他是 Apache Axis2 项目的联合创始人,也是 Apache Software 基金会的成员.他是 W ...
- 我总结的30条架构原则
本文作者叫Srinath,是一位科学家,软件架构师,也是一名在分布式系统上工作的程序员.他是Apache Axis2项目的联合创始人,也是Apache Software基金会的成员.他是WSO2流处理 ...
- 总结：Apache架构师30条架构原则
本文作者叫 Srinath,是一位科学家,软件架构师,也是一名在分布式系统上工作的程序员.他是 Apache Axis2 项目的联合创始人,也是 Apache Software 基金会的成员.他是 W ...
最新文章
- WinAPI: midiOutGetNumDevs - 获取 MIDI 输出设备的数目
- 易语言逐条读access数据_易语言对ACCESS数据库基础(适合新手)
- boost::signals2::signal_type相关的测试程序
- android NDk编程
- 织梦task_do.php,织梦20160906更新后栏目空白问题
- 敲了 10000 小时代码，我也没能成为一名高级程序员
- 李彦宏称有信心再赢 Google；京东网易拼团对抗拼多多；支付宝被罚 412 万后整改 | 极客头条...
- 【DEBUG】undefined reference to `cv_bridge::toCvShare
- SQL SERVER 锁定的实例
- 【.NET】Linq几样特点
- NBU官方Doc網址https://www.veritas.com/support/en_US/article.DOC5332
- http协议详解（超经典）
- 为什么有的PLC需要上电停止功能，能防止PLC变砖，可编程控制器 上电停止 串口通信 梯形图
- 常见问题数组索引越界异常
- 怎么制作GIF图片并添加文字
- jsp主机与asp主机的区别和支持分析
- 进安全模式提示”Press ENTER to continue loading SPTD.sys”
- 三种梯度下降的方式：批量梯度下降、小批量梯度下降、随机梯度下降
- TFTP和Syslog
- 编译原理实验三【中间代码生成程序设计】