接近零缺陷？ – 搞英语 → 看世界

在这个拥有强大软件缺陷查找工具的时代，我们看到这些工具能够快速发现大量问题。这给开发人员带来了难题，因为处理不断增长的问题列表变得异常困难。解决问题所需的时间可能比发现问题的时间还要长——更不用说将修复后的问题发布到新版本中，以及最终用户实际使用更新版本还需要相当长的时间。

为了快速发现大量漏洞，这些漏洞必须已经存在于源代码中。这些新工具不会添加或制造问题，它们只是找到问题，将其过滤掉并暴露出来。更好的过滤器可以过滤掉更多垃圾代码。

我们修复的漏洞越多，代码中剩余的漏洞就越少。前提是开发人员能够以足够快的速度修复问题。

我们合并的每个错误修复都存在风险，因为更改本身可能会引入一个新的或多个独立问题。此外，为了改进产品，我们往往会不断添加新功能并更改其行为，而这样做有时也会让我们疏忽大意，引入新的问题。

源代码分析工具的概念与源代码本身一样古老。一直以来都存在着用于识别代码错误的工具。而最近，这些工具的性能得到了提升，能够发现更多的错误。

这些新工具和旧工具一样，并不能发现所有问题。即使是这些现代化的新工具，有时也会给出一些不完整的、甚至是漏洞百出的解决方案。

毫无疑问，代码分析工具将会不断改进。未来的工具将会发现更多漏洞，其中一些漏洞是当前一代工具昨天扫描代码时未能发现的。

当然，我们现在也将这些工具引入到持续集成和通用开发流程中，这应该能帮助我们在未来交付质量更高、错误更少的代码。理想情况下是这样。

如果我们假设修复漏洞的速度比引入新漏洞的速度快，并且假设人工智能工具还能进一步改进，那么问题就变成了：它们还能改进多少？这种改进能持续多久？这些工具能发现多10%的漏洞吗？100%？1000%？这些工具的改进会在未来两三年、十年甚至五十年内持续进行吗？它们真的能发现所有漏洞吗？

我们能否达到这样的理想状态：在一个软件项目中完全没有bug，并且当我们合并一个新bug时，它几乎可以立即被检测和修复？

我们快到了吗？

如果我们假设至少在理论上存在达到那个点的可能性，我们如何知道何时达到那个点？或者甚至如何知道我们是否正在接近那个点？

我建议，衡量我们是否接近零缺陷目标的一个方法是检查已报告和已修复缺陷的出现时间。如果工具真的如此出色，我们应该很快就只需要修复最近引入的缺陷了。

在 curl 项目中，我们不跟踪普通 bug 的出现时间，但会跟踪漏洞的出现时间。漏洞是最棘手的那种 bug。如果工具能够发现几乎所有问题，那么它们很快也应该只会发现最近新增的漏洞。新发现漏洞的出现时间应该会急剧下降，最终趋近于零。

如果新报告的漏洞的年龄越来越小，那么随着时间的推移，整个漏洞集合的平均年龄和中位数年龄应该会下降。

当 curl 源代码中发现并报告这些漏洞时，平均和中位时间漏洞已经存在了一段时间。

当工具发现大部分问题后，需要修复的 bug 数量应该会减少。无论我们如何统计 bug 数量，或者我们对 bug 修复的定义多么宽松，bug 修复率都应该迅速下降。

根据 curl 项目的数据来看，bug 修复的数量似乎并没有减少——至少目前如此。或许 bug 修复的速度会先上升后下降？

从这些图表来看，我认为我们离零漏洞还很远。这两条曲线似乎都还没有开始下降。

是的，这些图表是基于单个项目的数据，因此很难从中得出统计结论，但这是我唯一能利用的数据。

我认为这主要表明了你认为这些工具能做什么，以及它们最终能变得有多好。

我不知道。我会继续修复漏洞。