代码错误代码_您的代码中有几个错误？

最新推荐文章于 2024-10-14 20:53:59 发布

danpu0978

最新推荐文章于 2024-10-14 20:53:59 发布

阅读量216

点赞数

文章标签： java python 人工智能编程语言大数据

原文链接：https://www.javacodegeeks.com/2011/08/how-many-bugs-do-you-have-in-your-code.html

版权

代码错误代码

当然，如果您遵循零错误容忍度，那么代码完成后就不应该修复任何错误。但是，让我们成为现实。有什么方法可以知道您遗漏了多少个错误，以后需要修复，以及您的代码中可能已经有多少个错误？您是否可以使用任何行业标准来衡量代码质量？

对于此类问题，我首先想到的是Capers Jones的著作之一：可以说是与软件开发指标有关的所有方面的领先专家。有应用软件评估，软件成本估算或软件工程最佳实践：顶级公司成功项目的经验教训。这些书对Capers Jones数十年来从数千个不同项目中收集的一组引人入胜的数据提供了不同的观点。花费数小时迷失在这个数据集中，通读并质疑他从中得出的发现很容易。

那么，我们可以从Capers Jones那里学到关于错误，缺陷可能性以及缺陷密度的信息吗？实际上很多。

在代码发布之前，平均有85％的设计和开发错误已被捕获（这是2009年美国的平均水平）。他的研究表明，缺陷清除率在20年中大致保持不变，鉴于当时工具和方法的进步，这令人失望。

我们为每个功能点引入5个错误（Capers Jones非常喜欢通过功能点来测量所有东西，这是一种测量代码大小的抽象方法），具体取决于所构建的系统类型。 Web系统的功能令人惊讶地更低，每个功能点有4个错误。其他内部业务系统为5个，军事系统平均为7个。使用回火（将功能点转换回LOC度量值的粗略技术），您可以将1个功能点等效于大约50-55行Java代码。

为了简单起见，让我们使用1个功能点= 50 LOC，并记住所有这些数字确实很粗糙，并且使用反向点火技术将功能点转换为源代码语句会引入错误的可能性，但这是比在功能点上思考要容易得多。我在这里只想知道一个团队可能会遇到的麻烦。

如果希望在发布代码之前发现并修复了85％的错误，那么在投入生产时，每个功能点将留下0.75个错误（并且显然是未修复的）。这意味着对于1000个功能点（50,000行左右的Java代码）的小型应用程序，发布时可能会有大约750个缺陷。

这只是考虑到您尚不了解的错误：发布了许多代码，其中列出了开发团队没有机会修复或认为不值得修复的已知错误列表，或者不知道如何解决。而且，这只是您的代码：它不考虑应用程序依赖的技术堆栈中的错误：框架和应用程序平台，数据库和消息传递中间件，以及您可以利用的任何开放源代码库或COTS。

在这750多个错误中，大约25％的错误将是严重程度为1的阻止程序-实际的生产问题会导致重大故障。

糟糕–难怪大多数团队在发布大型系统后都会花大量时间在支持和修复错误上。当然，如果您要逐步构建和发布软件，那么在进行过程中会发现并修复更多这些错误，但是您仍将在生产中修复许多错误。

请记住，这些是粗略的平均值。并记住（尤其是那里的其他人），无论我们想成为多少人，我们都不能高于平均水平。出于风险管理的目的，最好坚持平均水平，甚至认为自己处于最低水平。

另外请记住，潜在缺陷会随着系统规模的增加而增加– 大型应用程序平均存在更多错误。在较大的系统中编写错误代码的可能性不仅更高，而且随着代码库变得越来越大，越来越复杂，查找和修复错误的难度也越来越大。因此，大型系统会发布更多错误，而大型应用程序会发布更多错误。

所有这些使维护变得更糟

在维护中，进行更改的平均潜在缺陷要比开发中更高，每个功能点大约有6个错误，而不是5个。发现和修复更改中的错误的可能性更低（83％）。这就是所有的原因，因为您很难处理那些您未编写且不太了解的旧代码。因此，您应该期望在维护中更改代码时每个功能点发布1.08个错误，而不是每个功能点发布0.75个错误。

维护团队仍然必须处理系统中的潜在错误，其中一些可能会在代码中隐藏多年甚至永远。这包括heisenbug和幽灵，奇怪的计时问题和并发问题，当您尝试调试它们时就会消失。每个日历年平均发现50％的潜在残留缺陷。使用您的代码的人越多，发现这些错误的速度就越快。

当然，一旦发现这些错误，您仍然必须修复它们。一般的维护程序员每个月可以修复大约10个错误-也许还会实现一些小的改进。那不是很高的投资回报率。

然后是错误重新注入或回归的问题–当程序员意外地破坏某些东西作为进行修复的副作用时。平均而言，修复bug的程序员会在7％的时间内引入一个新的bug，对于复杂的，结构不良的代码，此错误的运行率可能高达20％。尝试修复这些错误的修复程序甚至更糟–尝试修复这些错误的程序员仍有15％的机会仍然搞砸该修复程序，而30％的可能性又引入了一个错误作为副作用！最好回滚该修补程序，然后重新开始。

不幸的是，随着时间的推移，所有这些都会变得越来越糟。除非您在重构和持续简化代码方面做得很出色，否则您可以期望代码复杂度每年平均增加1％至3％。随着时间的推移，大多数系统会变得越来越大，因为您添加了更多功能并复制和粘贴了代码（当然您不会这样做）：维护中的系统的代码库每年增加5-10％。随着代码变得越来越大，越来越复杂，出现更多错误的机会逐年增加。

但是，如果我们不算平均呢？如果我们是班上最好的怎么办？

如果您确实是班上最好的，那么如果您做得差不多完美呢？ Capers Jones发现，同类最佳的团队所产生的错误是普通团队的一半（每个功能点有2.5个或更少的缺陷，而不是5个缺陷），并且在发布代码之前，他们发现并修复了95％或更多的错误。这听起来令人印象深刻–这意味着每个功能点只有0.125个错误。但是对于50,000 LOC系统而言，交付时仍存在约125个错误。

至于零错误？在他40多年来对13,000个项目的分析中，有2个项目在发布后的一年内未报告任何缺陷。因此，您可以向往。但是不要依赖它。

参考： 错误和数字：您的代码中有多少错误？从我们的JCG合作伙伴 Jim Bird在Building Real Software博客中获得。

相关文章：