架构师必须了解的30条设计原则

前言

众所周知，架构师的角色，更偏向于策划、而非指挥，塑造、而非支配，其存在的意义，在于引导你们讨论、而非本身主宰一切。

可是，具体应该如何执行呢？本文做者整理了 30 个公认的架构原则，来帮助你们解决此问题。也许有的原则，你从未据说，但你看完就能快速学会。

基本原则

原则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人年的资源，不然不要去作。
最后，谈一下个人感觉。在理想状况下，一个平台应当由多个正交组件组成，每一个组件负责一个方面（例如，安全性、消息传递、注册、调解、分析，等等）。使用这些功能构建的系统将是最佳的。
不幸的是，现实中咱们很难达到这样的状态。由于在项目初始状态时，不少事情是不肯定的，你没法作到这样的独立性，如今我认为在开始的时候适当的重复是必要的，当你尝试铲除他们的时候，你会发现引入了新的复杂性，分布自己就意味着复杂。有时候治愈的过程要比疾病自己更加的糟糕。

总结

做为一个架构师，咱们应该像园丁同样思考、塑造、策划和去除杂草而不是定义和构建。虽然在短时间内，由一位架构师来制定架构的确既快捷又实惠。可是，从长远来看，团队的力量才是最强的。
若是你不够投入和细心，你只指出错误，可是不道明错误缘由，那么你的意见可能会让团队感到困惑。避免这种状况的一种方法是拥有一套广泛接受的原则，这些原则是讨论架构时遵循的基本点，也是初学者学习架构的好资源。因此想成为 一名优秀的架构师，仍是须要长期的磨练以及时间的验证，固然随时保持学习的状态也是很是重要的。当你学会更多知识，你便会更清晰的解决各类复杂的架构问题。

 

来源：Java面试那些事儿