问题解决和软件开发的脏盘子原则

在这篇文章中，我想和大家一起探讨解决各种任务和问题的成本。

在这篇文章中，我想和大家一起探讨解决各种任务和问题的成本。

更具体地说，让我们探讨一下解决问题的成本如何随着问题规模的增大而增长。

某些类型的问题具有线性成本函数。这意味着，如果问题规模翻倍，解决该问题的成本也会翻倍。

例如，读书或旅行——如果你花一个小时读完一本书的五十页，那么你可以得出结论，读两倍页数的书需要两倍的时间；或者，如果你花一个小时走完一段固定的路程，那么走两倍的路程需要两倍的时间（假设你保持相同的平均速度）。

然而，在许多问题中，成本函数是非线性的。实际上，这意味着随着问题规模的增大，求解成本会不成比例地增加。

脏碗碟原则？

以洗碗为例。如果午饭​​后只需要洗一个脏盘子，那没什么大不了的。但如果水槽里堆满了脏盘子，而且这种情况持续好几周，那问题就远比一个一个地清洗要麻烦得多（除非你用洗碗机，但这算是作弊）。

突然之间，水槽里的可用空间变小了，你需要格外小心，以免损坏其他餐具，由于盘子上的污垢已经变硬，你可能需要进行更多的擦洗和浸泡，这反过来又需要更多的肥皂，细菌可能会滋生等等。

洗碗的目标突然变得遥不可及，而且这项工作对任何人来说都不是件有趣的事。

一系列新的问题（需要解决，而且现在需要付出代价）仅仅是由于拖延和累积问题，任其不断扩大而产生的。当只有一个脏盘子时，这些问题并不存在。如果你在盘子脏了就立刻清洗，这些问题也根本不会出现。

我称之为“脏盘子原则”，它与软件工程非常契合。

它如何应用于软件开发？

以修复 bug 的指数级成本为例。如果在早期阶段，甚至在项目初期就发现 bug，修复成本就会非常低。因为 bug 存在的时间还不够长，不足以造成任何实际损害，而且你已经知道代码的哪一部分需要修复——上下文清晰易懂，所有这些都有助于快速轻松地解决问题。

但如果你没能找到漏洞，随着时间推移，问题会变得越来越棘手，解决起来也越来越费劲。突然之间，你不得不投入大量时间去弄清楚到底哪里出了问题，以及问题的原因。这个漏洞很可能已经给客户造成了困扰，损害了产品形象，并对未来的收入产生了负面影响。漏洞的最初作者可能已经跳槽到其他公司几个月了，相关的文档也所剩无几，没人知道代码的运行机制，而你却需要一位救世主来力挽狂澜。

仅仅是拖延和累积问题，任其不断扩大，就导致了一系列新问题（这些问题需要解决，而且现在需要付出代价）的出现。当只有一个脏污点时，这些问题并不存在。 盘子错误。如果没有你，这些问题就不会出现。 每道菜都洗干净了。尽快修复了所有漏洞。

这正是那堆脏盘子最终的下场，而最妙的是，这一切原本可以通过投资质量保证和软件开发最佳实践来轻松避免。例如，使用静态分析检查器。

另一个著名的例子清晰地阐释了这一原则，那就是“破窗理论”。该理论指出，放任小问题不管会导致整体情况恶化，最终花费更多成本来解决。这同样适用于软件工程，并凸显了重构技术部门和保持高质量标准的重要性。

关键在于——及时处理问题……

软件工程中充斥着大量这类代价高昂的非线性问题，无论是代码维护、系统设计、缺陷修复、算法分析，还是其他诸多领域。因此，了解哪些问题需要非线性解决，及早发现并尽快解决它们至关重要。

不要让问题越积越多，因为解决这些问题的代价最终可能会超过各个问题本身的代价之和。

祝你洗碗愉快！🙂