复杂性必须存在于某个地方

对抗复杂性是软件开发的一个反复出现的主题，我已经看到它一次又一次地重复自己。这是我一直看到的在各个层次上都在争论的事情：函数和方法应该进行多少评论？理想的抽象量是多少？一个框架什么时候开始有太多的魔力？一个组织中什么时候会有太多的语言？

我们试图摆脱复杂性，控制它，追求简单。我认为这样框定事情是被误导的。复杂性必然存在于某个地方。

弹性工程学教会我的一件事是控制论中的必备多样性的概念：只有复杂性才能处理复杂性。

如果您使构建工具变得简单，它将无法处理存在的所有奇怪的边缘情况。

如果您想要处理奇怪的边缘情况，您需要偏离您想要建立的任何规范。

如果您希望通用默认设置易于使用，则通用默认设置的规则必须在工具和用户之间共享，这些用户会根据工具的期望来调整自己的系统。

如果您允许配置或编写脚本，则为用户提供了一种指定必须共享的规则的方法，以便该工具适合他们的系统。

如果要使工具保持简单，则必须强制用户仅在符合此简单性的参数范围内进行操作。

如果您的用户用例不能很好地与您的简单性相匹配，他们将围绕您的工具构建填隙程序以实现其目标。

这是无法避免的。复杂性必然存在于某个地方。不管你是否意识到，它总是人们解决问题的一部分。

不幸的是，如果我们到了清单的最后一点(我们总是以某种方式做到这一点)，垫片就会成为风景的一部分。复杂性不会潜伏。这是每个人学习经历的一部分，他们会适应它。

他们绕过它，看到两个相互冲突的概念之间的不匹配。这种必要的复杂性可能会移动-回到工具(或新工具)-或者通过重新组织事物来消除。每一次这样的改变都需要付出努力，需要更多的调整，人们需要看到复杂性，理解复杂性，处理复杂性。在某些情况下，变化不会简化事情，它们会通过在不同人的假设之间创造新的不匹配而使事情复杂化，这将…。

在“日常事物的设计”中，唐·诺曼提到了头脑中的知识和世界中的知识的概念(类似的概念在Roesler&；Woods&39；Design for Experts一书中更具学术性)。头脑中的知识是你知道的、你学到的、存在于你记忆中的东西。世界上的知识就是一切：记录下来的信息，设计中的提示(你通过看它的符号就知道电源按钮，你知道它可以……。

在某些方面，专业知识就是在你的头脑中拥有让你更好地阅读世界的知识。

我们在软件设计中遇到的一个常见陷阱来自于关注我们发现它是如何阅读和解释给定的代码片段的。专注于简单性充满了危险，因为复杂性是无法消除的：它只能四处移动。如果您将其移出您的代码，它会去哪里？

当我们设计Rebar3时，我们觉得这个工具可以很简单。其简单性的条件是您对Erlang/OTP项目的预期结构有一个基本的了解。只要你遵循这些规则，事情就会进展顺利。我们将一些复杂性外化到更广泛的生态系统中。规则总是需要学习的(我们是这样假设的)，但是工具现在依赖于对它们的理解。在为了解规则的人简化工具使用的过程中，我们使……。

这种陷阱在软件体系结构中是隐蔽的。当我们采用像微服务这样的东西时，我们会努力使每项服务都是单独简单的。但是，除非这种简单性太过束缚，以至于您的实际应用程序继承了它并被迫变得简单，否则它仍然必须去某个地方。如果它不在单个的微服务中，那么它在哪里？

复杂性必然存在于某个地方。如果你幸运的话，它生活在定义明确的地方。在您决定稍微复杂的代码中，在支持代码的文档中，在工程师的培训课程中。你给它一个地方，而不是试图把它全部藏起来。你可以创造方法来管理它。当你需要它的时候，你知道去哪里见它。如果你不走运，只是试图假装复杂性可以完全避免，那么它在这个世界上就无处可去了。..。

在无处可去的情况下，它不得不在您的系统中到处漫游，无论是在您的代码中，还是在人们的头脑中。随着人们四处转移和离开，我们对它的理解也会受到侵蚀。

复杂性必然存在于某个地方。如果你拥抱它，给它应有的位置，在知道它存在的情况下设计你的系统和组织，并专注于适应，它可能只会成为一种压力。