软件熵

想象一下一个干净的鞋柜，所有的鞋子都是按颜色配对和分类的。壁橱的熵是它的鞋子可以有的排列总数。干净壁橱的熵相对较小。可能会有几双灰色或蓝色的鞋子可以调换，但这并不会增加太多的复杂性。在熵较低的壁橱中，根据需要可以很容易地从壁橱中添加或移除鞋子。

现在想象一下一个凌乱的鞋柜。没有一双鞋是成对的，它们都缠在一大堆里。这些鞋子可以有几种可能的组合？你可以试着拿出你想要的那双，很快就知道了。凌乱的鞋柜比干净的鞋柜熵大得多。

简而言之，我们通过计算系统可能处于的状态数来测量熵。更多的状态意味着更多的熵。

在软件中，我们的构建块非常简单，我们可以用一种粗略的方式来测量熵。以此模型为例：

看起来很简单，这个型号就像我们凌乱的鞋柜。这个模型有很多错误的地方，而不是正确的地方。我们可以通过将它与一个有组织的鞋柜进行比较来看出这一点：

当`createdAt`是任意字符串时，它可以像有效值“06-23-2020”一样容易地接受无效值“foo”和“bar”。该字段可以处于更多可能的状态，其中大多数都是无效的。这种宽泛数据类型的选择使我们的模型变得混乱。这种不想要的混乱会导致误解、错误和浪费能量。

当每个模型都强类型化为一组严格的值时，这种混乱就会最小化。DateTime、UserID和Price的类型化使得所有可能的值都是有效的。因此，这些类型更可预测，更易于操作，并且在实践中不会带来太多意外。

就像在生活中一样，熵也不全是坏事--有些是可取的，有些是不可取的。在软件中，我们在一定程度上需要熵：我们的代码很有价值，因为它支持各种可能的日期、用户和价格。但是，当这种混乱发展到超出它所增加的价值时，我们的软件就会变得使用起来很痛苦，维护起来也很痛苦。

只有几种可能状态的构造是简单的。布尔值和枚举比字符串简单得多。一个移动件的系统比多个移动件的系统简单得多。

有时，我们的问题本质上是复杂的。在这些情况下，我们的解决方案需要一些基本的复杂性来匹配。但是，什么时候基本的复杂性变得不必要了呢？在这些情况下，我们可以使用另一个规则：

如果总共有数千种可能的状态，但只有两种状态是有效的：这是一个混乱的解决方案。这方面的一个简单示例是将布尔值表示为字符串。

这段代码出错的原因有很多，不仅是在执行过程中，在解释过程中也是如此。保持解决方案的整洁可以提高正确性、可读性和可维护性。在我看来，这是衡量“质量”的主要标准之一。

有没有什么方法可以通过削减总的可能状态数来使解决方案变得更简单？

有没有办法通过削减无效可能状态的数量来使解决方案变得更干净呢？

这个概念的强大之处在于它可以在抽象的阶梯上平滑地上下伸缩。它适用于基本数据类型，就像它适用于解决方案体系结构和产品开发一样。

我们的解决方案需要多少个移动部件？当一个难以想象的需求飞来，试图将我们的解决方案打倒在地时，还能剩下多少块呢？当意外输入到达时，无效状态是会在整个系统中传播，还是一看到就会被包含和消除？简而言之，我们的解决方案有多干净？

为了使生活成为可能，我们通过创建支持不同人群及其用例的复杂系统来利用混沌。为了让生活变得可预测，我们通过尽可能保持这些系统的清洁和有序来对抗不受欢迎的混乱。

在软件领域，我们所处的世界是可以衡量混乱的，可以实现清洁的。我们只需要一组正确的信号和反应来实现这一点。