架构设计-复杂度是不灭的

架构师（JiaGouX）我们都是架构师！
架构未来，你来不来？

因公众号更改推送规则，请点“在看”并加“星标”第一时间获取精彩技术分享

与复杂度的斗争是软件开发的一个永恒的主题，我一次又一次地看到它反复出现，并且不断在各个层面上看到有关的争论：到底应该在函数和方法中进行多少注释？理想的抽象是怎样的？一个框架何时开始拥有了「过多的魔法」？什么时候组织中有太多语言？我们试图摆脱复杂度，控制它，寻求简单性。我认为以这种思考方式来寻求问题的解决方案是错误的。因为复杂度必须存在于某个地方，是不灭的。Resilience Engineering教给我一个来自控制论的“必要多样性”概念：「只有复杂度才能处理复杂度。」在处理构建工具时，一些事情变得显而易见：

• 如果你让构建工具变得简单，它就不能处理所有存在的奇怪的边缘情况。
• 如果你想处理奇怪的边缘情况，就需要偏离你想建立的任何规范。
• 如果你想让通用默认值易于使用，那么通用默认值的规则必须在工具和用户之间共享，而用户则要改造自己的系统来适应工具。
• 如果你允许自主配置或编写脚本，你就给了用户一种方法来指定必须共享的规则，以便工具适合他们的系统。
• 如果你想保持工具的简单性，你就必须强迫你的用户只在适合这种简单性的参数范围内玩耍。
• 如果用户的用例不能很好地与你的工具简单性相匹配，他们就会在你的工具周围建立垫片（周围的小工具）来实现他们的目标。

这是无法避免的。复杂度必须存在于某个地方。无论您是否意识到，它始终是人们解决问题时需要注意到的。不幸的是，如果我们做到了列表的最后一点（我们总是以某种方式这样做），垫片就会成为整体工具的一部分。复杂度并不会消失。这部分复杂度是每个人必须要学习的，用户会需要适应它。他们尝试绕过复杂度时，看到了两个冲突的概念（译者注：类似ORM中的O和R的概念）之间的不匹配。这种必要的复杂度可能会转移——回到工具（或新工具）——或者通过重新构建事物来消除。每一个这样的变化都需要付出更多的努力和调整，让人们看到复杂度，理解它，并解决它。但是在某些情况下，这种变化不会使事情简化，而是会在人们的各种假设之间产生新的不匹配，从而使事情复杂化，这就需要新的垫片。必然复杂度时间久了之后，就变成了偶然复杂度。它无法避免，而且它一直在变化。复杂度必须存在于某个地方。在《The Design of Everyday Things》中，Don Norman提到了“头脑中的知识”和“世界中的知识”的概念（类似的概念更学术话的出现在了Roesler&Woods的《Designing for Expertise》）。头脑中的知识是你知道的、你学到的、你记忆中的东西。世界上的知识是其他的一切：写下来的信息，设计中的线索（你通过看它的符号知道电源按钮，你知道它可以被按下，因为它看起来像一个按钮）。一件棘手的事情是，对世界上的知识的解释既有文化上的，也有上下文上的，并且依赖于头脑中的知识（你知道电源按钮可以被按下，因为你知道按钮首先是什么）。在某些方面，专业知识是在你头脑中可以使你能更好地了解世界的知识。将精力放在发现阅读和解释一段特定的代码有多“简单”是我们在软件设计中的一个常见的陷阱。专注于简单性是充满危险的，因为复杂度无法消除：它只能被转移。如果你把它从你的代码中移出来，它去了哪里呢？当我们设计Rebar3时，我们觉得这个工具可以很简单。其简单的条件是，你对Erlang/OTP项目的预期结构有一个基本的了解。只要你遵循这些规则，项目就会运转的很好。我们把一些复杂的东西外化到更广泛的生态系统中。这些规则总是需要学习的（我们是这么认为的），但现在的工具取决于对它们的理解。在为了解规则的人简化工具的使用时，我们使那些仍在学习规则的人更难使用。在其他生态系统中用于其他目的的工具都在做类似的权衡。这个陷阱在软件架构中是隐蔽的。当我们采用微服务之类的东西时，我们会尽量使每个服务都变得简单。但是除非你能够使你的真实应用可以强制进入简单的状态，否则复杂度仍然必须去某个地方。如果它不在各个微服务中，那么它在哪里（译者注：使用微服务的人仍然要知道规则是什么，如何使之简单）？复杂度必须存在于某个地方。如果你幸运的话，复杂度在定义明确的地方。在你认为有点复杂的代码中，在支持代码的文档中，在工程师的培训课程中。你给了复杂度一个地方，而不是试图隐藏它。你创造方法来管理它。你知道当你需要它的时候，该去哪里找它。如果不走运，你只是试图假装复杂度可以完全消除，那么它在这个世界上就没有地方可去。但它仍然会一直存在于这个世界。由于无处可去，复杂度不得不在你的系统中到处游荡，包括在你的代码中和人们的头脑中。随着人的转移和离开，我们对它的理解逐渐减弱。复杂度必须存在于某个地方，它是不会消失的。如果你接受它，给它应有的位置，在设计你的系统和组织时知道它的存在，并专注于适应它，它可能就会成为帮助软件架构设计的一种力量。

如喜欢本文，请点击右上角，把文章分享到朋友圈
如有想了解学习的技术点，请留言给若飞安排分享

·END·

相关阅读：

---

作者：姚钢强

来源：https://docs.google.com/document/d/1Qp2foEIk2Tn0x-hwM3-3FeFf3sADnhMabQGOkgE09QI

版权申明：内容来源网络，仅供分享学习，版权归原创者所有。除非无法确认，我们都会标明作者及出处，如有侵权烦请告知，我们会立即删除并表示歉意。谢谢!

架构师

我们都是架构师！

关注架构师(JiaGouX)，添加“星标”

获取每天技术干货，一起成为牛逼架构师

技术群请加若飞：1321113940 进架构师群

投稿、合作、版权等邮箱：[e-mail]