在软件开发工作流程中，检测和修复软件缺陷的成本随着时间的推移呈指数级增长。在现场修复缺陷的成本高得惊人，而且风险很大--往往是一个或两个数量级的。这种成本不仅体现在目前所浪费的时间和资源上，而且还体现在未来所失去的机会上。
大多数缺陷最终花费的成本比预防它们的成本要高。缺陷发生时是很昂贵的，包括修复缺陷的直接成本，以及由于关系受损、业务损失和开发时间损失而产生的间接成本。- Kent Beck, Extreme Programming Explained
NIST提供的下图有助于直观地了解，随着软件在软件开发的五个大阶段中的发展，检测和修复缺陷的工作是如何增加的。
为了理解为什么成本会以这种方式增加，让我们考虑以下几点。
-
当开发人员还在编写代码时，检测代码中的问题要容易得多。因为代码在脑海中还很新鲜，即使是复杂的问题也很容易修复。随着时间的流逝，代码进入后期阶段，开发人员需要记住所有的东西，并在修复问题之前追寻到它们。如果一个自动化的系统，比如持续质量集成，在开发人员还在写代码的时候就能突出代码中的问题，那么出于同样的原因，他们会更乐意加入修复。
-
一旦软件进入测试阶段，在开发人员的本地环境中重现缺陷又是一项耗时的工作。此外，虽然很容易发现一些明显的缺陷或不符合要求的东西，但要发现更基本的缺陷是非常困难的--想想内存泄漏、竞赛条件等。如果这些问题在编码阶段就被发现了，那么它们通常要到生产阶段才会出现，这很不幸。
-
在软件发布并投入使用后，不仅难以发现缺陷，而且风险也非常大。除了防止现场用户受到问题的影响之外，确保服务的可用性也是业务的关键。这些影响是复杂的，与早期修复这些缺陷相比，增加的成本高达 30 倍。
缓解措施
尽管有上述争论，但实施使开发人员能够早期发现、经常发现的流程是很有价值的。从本质上讲，开发工作流程应该确保尽可能早地发现缺陷--最好是在开发人员编写代码或在合并到主要开发分支之前的代码审查阶段。
像持续集成这样的流程有助于确保对代码的修改是小而可控的，所以更容易发现问题。跟踪代码覆盖率并确保一定的阈值是有帮助的，并促进对代码的迭代以修复这些问题。实施静态分析可以通过自动检测数百个错误风险、反模式、安全漏洞等来帮助保持代码的清洁。
从本质上讲，流程和惯例应该围绕着将缺陷检测移到工作流程的早期，并尽可能地接近开发者的编码环境而设计。这样一来，扩大晚期缺陷检测负面影响的复合效应就会有利于提高软件质量和复原力。
