如果成本是非线性的，则保持较小

我们喜欢效率。当我需要修理屋顶板并清理排水沟时，我想在屋顶上进行一次旅行。当我洗衣服时，每次旅行都会将两个负载移到地下室。当我的应用程序需要升级其依赖项时，我会立即升级一大堆…对吗？

我们喜欢批处理。分批处理比一次，一，二，一，一等的效率更高，一次执行十次的速度更快。我不脱下袜子就立即洗袜子，因为将袜子与下一个负载混在一起是免费的。

直到需要清理排水沟时，保存带状疱疹的修复是否更有效率？不清楚

它显示了预防性维护的一系列小成本。小型维修会产生一系列较大的费用，而大型维修则要大得多。每次维护延迟都会升级为小修，然后是大修-成本随着时间的延迟而非线性增加。

如果我等到Spring修理带状疱疹，水会渗入阁楼并造成更多损失吗？如果今年我不清理排水沟怎么办？明年我们将清理两次叶子，仅此而已！哦，不，我现在有水损坏，需要大修。这花费了超过三次到屋顶的行程。

当成本随着延迟或批次大小非线性增加时，更大的批次效率不高。

就像DevOps和CI / CD：更频繁地部署更安全。发生这种情况是因为每个部署包含较少的更改。每次更改都可能导致问题，并且在出现问题时都可以怀疑每次更改。 1变化，1问题？ 1名嫌疑犯。 2个变化，1个问题？ 2名犯罪嫌疑人。 17个变化，3个问题？ 51名嫌疑犯-！

这是非线性关系。变更会相互影响，因此将其分批进行批处理将使您的批处理成本增加的成本超过您要添加的更改的成本。批处理效率较低。

这就像您的袜子想吃另一件衣服一样，所以您放进去的东西越多，花费的时间就越多。 （这没有意义，但这有点可笑。）

分批洗衣服。袜子，衬衫和毛巾互相独立地保持清洁。警告：这假设您有足够的干净袜子来同时让脚保持温暖。

这发生在家庭维护和部署中。保留功能延迟会增加价值。库升级的缓慢推出使您容易受到已发布漏洞的影响。可能导致漏水或数据泄漏。

由于变更交互，因此每次变更所带来的部署成本要比单独部署变更所带来的成本增加更多。库升级也是如此。当您升级一个库时，出现问题时，您对导致它的原因有一个不错的认识。这不是一个完美的主意，因为所有这些可传递依赖项都已升级（boo）。不过，这比升级多个库然后解决至少一个问题要好。这要困难得多。

立即升级，而不要分批升级。这样可以确保您的应用程序尽可能安全，并使工作更轻松。

升级库没什么好玩的。将梯子从车库中带出并爬到屋顶上是很多工作。但这可以防止房屋漏水，也可以防止代码泄露用户凭据给攻击者。如果您今天不在阳光下这样做，那么您将在卧室天花板将水滴在睡着的脸上或必须向新闻界宣布违规情况时这样做。

定期进行轻松无聊的工作，而不要在惊慌中进行艰苦的吓人工作。