复杂性必须存在某个地方

Posted 2020-12-22 wust-hy

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了复杂性必须存在某个地方相关的知识，希望对你有一定的参考价值。

对抗复杂性是软件开发中一个反复出行的主题。

在各个不同的层面上都有不同的谈论：

1. 如函数或者方法的大小；

2. 抽象的多少；

3. 框架在什么时候开始有‘很多的魔力‘;

4. 一个组织中语言的种类

我们试图去避免复杂性，控制复杂性，追求简洁。但是在我看来用这种方式

做软件的架构其实是误导，复杂性必须存在于某个地方。

弹性工程关于控制必要变量的理论是：只有复杂性才能处理复杂性。

当处理构建工具时，一些观点已经变得明朗：

1. 如果构建工具过于简单，则不可能处理所有的边缘异常情况

2. 如果要处理奇怪的边界情况，则有可能脱离你所建立的规则

3. 如果希望对常见的场景易于使用，则常见的默认场景需要分享给使用

工具的用户，他们来调整自己的系统以适应工具满足的场景

4. 如果允许配置和自定义脚本，并且把自定义的规则分享给用户，这样使得

工具满足用户的系统需求

5. 如果想保持工具的简洁，则必须强制用户在参数允许的范围内使用

6. 如果工具不满足用户的需求，则用户会构建一些围绕该工具的shims来满足

用户自己的需求

如果以最后一点为原则来构建工具，则围绕系统的shims也会成为该工具的一部分

复杂性并没有消减，这是所有人学习经验的一部分，并且适应了这种方式。

对现实世界知识的解释既需要文化知识也需要上下文，同时也依赖接收者的认知。

在某些方面，你头脑中的专业知识，使你更好的认知世界。

当我们设计Rebar3时，我们觉得工具应该是简单的。简单的前提是你必须对Erlang/OTP项目结构

有基本的了解，只要你遵循这些规则，工具会变得容易理解。我们把一些复杂性扩展到了更广的生态中。

那些规则需要一直被学习，但是依赖这些规则的工具变得容易理解。

这个道理在软件架构中是隐蔽的。当我们采用微服务架构时，我们试图让每个微服务变得独立简单。

但是除非这种简单具有约束性，并且在应用这种约束性使得应用变得简单，否则复杂性还会在其他的

地方体现。如果不是在单独的微服务，还会在哪里呢？

复杂性必须存在于某个地方，如果你幸运的话，它存在预先良好定义的地方--在代码里

承担了一些复杂性；在文档里支持复杂的代码说明；训练自己的工程师认知这种复杂性。

你给了合适的位置来组织这种复杂性而不是隐藏所有的复杂性。你创建方式来管理它，并且

知道在什么地方发现它在你需要的时候。

复杂性没有地方隐藏，它会在你的系统中到处游走，不仅在代码中也在用户的头脑中，当用户

注意力转移时，对系统的理解也会减弱。

复杂性必须存在于某个地方，当你拥抱它，把它放在合适的地方，设计你的系统和组织，

理解它的存在，同时专注于适应复杂性，则复杂性会变成一种力量。

以上是关于复杂性必须存在某个地方的主要内容，如果未能解决你的问题，请参考以下文章