对抗复杂性是软件开发中一个反复出行的主题。
在各个不同的层面上都有不同的谈论：
1. 如函数或者方法的大小；
2. 抽象的多少；
3. 框架在什么时候开始有'很多的魔力';
4. 一个组织中语言的种类
我们试图去避免复杂性，控制复杂性，追求简洁。但是在我看来用这种方式
做软件的架构其实是误导，复杂性必须存在于某个地方。
弹性工程关于控制必要变量的理论是：只有复杂性才能处理复杂性。
当处理构建工具时，一些观点已经变得明朗：
1. 如果构建工具过于简单，则不可能处理所有的边缘异常情况
2. 如果要处理奇怪的边界情况，则有可能脱离你所建立的规则
3. 如果希望对常见的场景易于使用，则常见的默认场景需要分享给使用
工具的用户，他们来调整自己的系统以适应工具满足的场景
4. 如果允许配置和自定义脚本，并且把自定义的规则分享给用户，这样使得
工具满足用户的系统需求
5. 如果想保持工具的简洁，则必须强制用户在参数允许的范围内使用
6. 如果工具不满足用户的需求，则用户会构建一些围绕该工具的shims来满足
用户自己的需求
如果以最后一点为原则来构建工具，则围绕系统的shims也会成为该工具的一部分
复杂性并没有消减，这是所有人学习经验的一部分，并且适应了这种方式。
对现实世界知识的解释既需要文化知识也需要上下文，同时也依赖接收者的认知。
在某些方面，你头脑中的专业知识，使你更好的认知世界。
当我们设计Rebar3时，我们觉得工具应该是简单的。简单的前提是你必须对Erlang/OTP项目结构
有基本的了解，只要你遵循这些规则，工具会变得容易理解。我们把一些复杂性扩展到了更广的生态中。
那些规则需要一直被学习，但是依赖这些规则的工具变得容易理解。
这个道理在软件架构中是隐蔽的。当我们采用微服务架构时，我们试图让每个微服务变得独立简单。
但是除非这种简单具有约束性，并且在应用这种约束性使得应用变得简单，否则复杂性还会在其他的
地方体现。如果不是在单独的微服务，还会在哪里呢？
复杂性必须存在于某个地方，如果你幸运的话，它存在预先良好定义的地方--在代码里
承担了一些复杂性；在文档里支持复杂的代码说明；训练自己的工程师认知这种复杂性。
你给了合适的位置来组织这种复杂性而不是隐藏所有的复杂性。你创建方式来管理它，并且
知道在什么地方发现它在你需要的时候。
复杂性没有地方隐藏，它会在你的系统中到处游走，不仅在代码中也在用户的头脑中，当用户
注意力转移时，对系统的理解也会减弱。
复杂性必须存在于某个地方，当你拥抱它，把它放在合适的地方，设计你的系统和组织，
理解它的存在，同时专注于适应复杂性，则复杂性会变成一种力量。