关于程序员的从不、偶尔和总是

在软件开发中，我们经常使用零、一、无穷、规则（或“零一多”）来决定应该允许多少个实例。

例如，数据库中的客户记录可能没有与之关联的电子邮件地址，可能只有一个电子邮件地址，也可能有多个电子邮件地址。如果您目前支持一个电子邮件地址，而有人说他们需要两个，那么您应该跳过两个，直接无限增加。只添加对第二个电子邮件地址的支持是一个坏主意，因为您仍然需要处理可变数量（一个或两个），因此处理任何数量实际上都更简单，而且您还能应对未来。

事件频率也有相似之处：就像程序员只关心数字 0、1 和 ∞ 一样，我们关心的只有三个频率，即从不、有时和总是。

我经常和客户进行这样的对话：

我：有可能出现 X 情况吗？

客户：不，不，不。这种事不会发生。几乎不会发生。

问题是“几乎从不” 仍然是 “有时”，因此客户的反应在不到一秒钟的时间内从肯定的“不”变成了肯定的“是”。这种情况很少发生对我来说并不重要——这种情况仍然会发生，我必须编写代码来应对它。代码不经常使用这一事实并不意味着编写成本更低——这不像工程，使用较少的机器需要的维护较少。

事实上，处理“几乎从未发生”的情况可能要花费更多成本，因为，例如，可能更难找到或构建用于测试的示例。如果构建一个特殊的代码分支来处理罕见的情况，那么这种代码可能测试得更差，错误更多，从长远来看，成本比处理常见情况的代码更高。

这种事情经常发生在客户从手动系统转换时，在手动系统中，所有输入都由智能代理处理，所以不会造成太多问题，因为人只是做了一些明智的事情。因此，对于客户来说，可能会觉得我过于迂腐，把所有的精力都集中在怪异的情况上——但在转换为计算机系统时，我们没有智能代理在驾驶，所以每个情况都必须得到解决。尽早了解怪异的情况实际上有助于我想出一种设计，其中这些情况根本不是例外，它们只是正常操作，不需要任何额外的代码——这使得设计更加健壮。

事实上，几乎从未意味着频率相对较高——这可能意味着你过去至少目睹过一次这样的情况，所以这肯定是有时。更棘手的情况是诸如从未发生过，这只意味着你没有亲眼见过这种情况，但没有理论上的理由说明它不可能发生。换句话说，有时。然后是永远不会发生，这时我的直觉告诉我“它会发生，而且可能比我们预期的要快”。所以，再说一次，这是有时。

👀

   

注意事项

当然，有时程序员确实关心相对频率——1% 与 10% 或 90% 有很大不同——其中大多数都属于“优化”范畴。

如果你是一名戴着产品经理帽子的程序员，你当然可以生产出“80% 解决方案”甚至“20%”解决方案，但要知道你的产品根本无法应对某些情况，人们需要寻找其他解决方案。你正在针对业务需求层面的常见情况进行优化，你会想知道这种常见情况是什么。

您可能还会关心其他优化类型的相对频率，例如性能或用户界面设计。例如，您可以拥有一个在典型情况下运行良好但在特殊情况下更笨重的界面。

但即使在这里也存在危险。假设你针对 99% 的时间发生的情况优化算法，这样你就得到了正常工作负载的线性时间复杂度。不幸的是，对于 1% 的情况，你会陷入更糟糕的时间复杂度，比如二次时间。你仍然必须处理 1%，此时你的系统可能会崩溃。这可能已经糟糕到代码实际上对用户来说根本不起作用。或者，如果我们谈论的是你运行的服务，我们知道 80%以上的性能问题发生在 20%的代码逻辑里面，以至于从资源方面来看，你的 1% 的情况实际上是 99% 的问题。

此外，如果您在互联网等恶劣环境中运行，攻击者可能会强制执行最坏的情况性能，现在您就存在拒绝服务漏洞。

在代码处理“罕见”情况的方式上，您可能还会有定性和定量差异。在最底层，可能要添加一个断言，如果发生不太可能发生的事情，该断言将失败并导致进程崩溃，假设这不会是一个严重问题，并且您会收到通知。然后，一旦您开始收到这些通知，您就可以评估是否值得投入更多资源。

我能想到的最后一个警告是，总有一个临界点，在这个临界点上，你可以把极不可能发生的事件算作“从不”。例如，像 SHA-256 这样的 256 位哈希函数发生碰撞的几率大约是万亿分之一。从技术上讲，这是“有时”，但将其算作“从不”是相当合理的。当然还有 MD5.....

---

原创不易，随手关注或者”在看“，诚挚感谢！