怎样才能减少软件中的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数、给星数或提交次数。

（编辑：河北网）

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