怎样才能减少软件中的Bug？数据显示程序员才是制造 Bug 的“元凶”

代码的 Bug 到底与什么有关？代码的行数？项目的规模？还是开发者的人数？在本文中，将基于机器学习模型绘制的图形，告诉你诸多 Bug 的由来！

以下为译文：

怎样才能减少软件中的Bug？本文将告诉你传统观点是错误的，下列数据会让你感到惊讶。

软件开发人员普遍认为，代码量越大Bug就越多。虽然许多人并不是很清楚这两者之间的确切关系，但他们认为二者是线性的关系，即每千行代码中的Bug数与代码量成正比。然而，根据对GitHub中最受欢迎的10万个代码库的研究发现，代码行数与Bug之间并不存在这种恒定的关系。而且，代码行数并不是Bug数的可靠指标。

注：在本文中，我用“bug”来指代软件中从一些从用户的角度来看的异常行为，例如：死机、视觉异常、不正确的数据等。“Bug”也常用于描述软件中可利用的缺陷，但这是从攻击者的角度来看。本文不涉及安全漏洞，因为安全漏洞可能需要别的模型来分析。

相反，我们发现了两个更可靠的指标：贡献代码的开发人员数量和提交代码的次数。本文中的图片使用了一个拥有两个变量的模型，而且这个模型在预测Bug数目时，与我另一个拥有16个变量的模型表现几乎相同。我会详细解释这些模型的建模过程，但是首先：

如果存在这种因果关系，那么这对减少Bug意味着什么？

如果你需要可靠的软件，那么请不要使用会产生Bug的方法论。例如，敏捷主张直接写代码，然后通过迭代这些代码来优化需求，所以会产生很多提交（而提交次数与bug数息息相关）。

原型可以减少bug，但是你必须在使用完后丢弃这些原型。你需要通过数次提交来学习技术和客户的需求，然后编写一个非原型版本，其中包含更少量的提交次数和/或更小的团队。

刻意保障系统可靠性的工作可能会产生相反的效果。在采用测试驱动的开发和单元测试的情况下，如果提交的代码次数，或需要的开发人员的话，那么bug数也会，这可能与你的直觉恰恰相反。

对于个人而言，你应该将时间花费在写代码之外的事情上，例如思考、设计、和制作原型等等。

对于企业而言，雇佣的开发人员数量越少越好，当然开发人员的经验越多越好。

收集数据

首先，我通过GitHub API，查询了10万个最受欢迎的项目（超过135颗星的项目）。这些项目并不是随机抽样，它们占据了GitHub上最顶级的0.1%，所以我们更加自信会有很多人发现和报告bug。对于每个项目，我提取了项目的创建日期（GitHub上的日期），给星数量，问题数量，提交PR的次数，以及issue tracker是否被禁用。

接下来，我克隆了所有非私有的代码库，并直接从Git和文件系统收集了以下统计信息：

最后，我针对每个代码库的HEAD信息，收集了Tokei的统计信息：每种检测到的语言的代码行数、注释、空格等等。然后，对于每种Tokei检测到的语言，我计算了总字节数和LZMA压缩后的字节数。

排名前50的总代码行数。被排除的语言（文本和标记）用灰色显示（Text、Html、Markdown、Sg、ReStructuredText）

控制受欢迎度等差异

我们以为，旧项目和受欢迎项目的平均bug数会更偏高。为了控制这些差异以及其他差异，我使用了如下模型：

ln(issues) = β1created age + β2first commit age + β3ln(stars) + β4ln(contributors) + β5ln(all commits) +β6ln(code) + β7ln(comments + 1) + β8ln(pull requests + 1) + β9ln(files) + ε

我通过这个模型做了拟合，并通过10折交叉验证测试了模型与线性回归的拟合度，然后在一个组合图中绘制了每个折叠的预测误差。在此之前，我删除了所有私有、归档、镜像和分叉项目，没有启用issue tracker的项目，以及数据集中bug数为零的项目。

9个变量模型的预测误差

这个模型有一些偏差，但其他方面的拟合度还不错。它高估了GitHub上问题数量很少（<10）的项目的bug数（相反低估了问题数量偏高的项目）。我怀疑这是由于github的api中没有将分叉项目标记出来，还有一些包含第三方代码的项目导致的。这些项目夸大了与issue>

ln(issues) = β1ln(code) + ε

ln(issues) = β1ln(lzma bytes) + ε

仅包含代码行或lzma压缩的代码字节的模型（说明了语言之间代码密度的差异）表现同样糟糕。

用9个变量的模型拟合完整的数据集后，得出了以下近似值：

ln(issues) = 0.022created age – 0.017first commit age + 0.315ln(stars) + 0.071ln(contributors) + 0.266ln(all commits) +0.072ln(code) + 0.034ln(comments + 1) + 0.413ln(pull requests + 1) – 0.069ln(files) – 1.690

我们可以看出，模型中的主导变量是PR数（0.413）、给星数（0.315）和提交次数（0.266）。将这二者与代码行数（0.072）和注释（0.034）相比较，就会发现这些差异更加明显，尤其是再考虑到变量尚未规范化，而且几乎所有项目中代码行数都会高于PR数、给星数或提交次数。

（编辑：财气旺网 - 海宁网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!