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

由于PR数和给星数是GitHub特有的功能，我还构建了一个没有这两个数据项的模型。然后，根据拟合模型的系数，再进一步将其简化为只包含提交代码的人数和提交次数。这种只有3个变量的模型的表现几乎与其他模型完全相同，而且还可以显示成3G图形：

ln(issues) = β1first commit age + β2ln(contributors) + β3ln(all commits) + β4ln(code) + β5ln(comments + 1) + β6ln(files) + ε

ln(issues) = β1ln(contributors) + β2ln(all commits) + ε

在删除了GitHub特有的数据项后，提交代码的人数和提交次数就占据了主导地位，从删除所有其他变量时错误数轻微的减少就可以看出。

会不会是这个模型搞错了？

现在我们知道了提交代码的人数和提交次数的影响，下面我们来看看，如果不采用任何根据提交代码的人数和提交次数绘制图形的模型，那么代码行数与问题数量之间有何关系。

针对GitHub上最受欢迎的项目，绘制代码行数（x轴）与GitHub上的问题数（y轴）的关系图，并根据提交代码的人数和提交次数分组。

为了节省空间，我没有显示所有的10万个顶级项目。我按照提交代码的人数和提交次数进行了分组，因为我觉得这种分组方式最有意思，且最具代表性。为了避免选择偏差，我只在选择分组之后进行绘图。

你只看到了一团团杂乱的点，对吧？这就对了：上图证实了代码行数与bug数之间的关联性非常弱。而且请记住，这些图是用对数绘制的，而且这个模型使用的是ln(code)（代码行数的对数）：因为相关性会随着代码行数的大小而变化。

随着代码行数的增加，bug数却增长缓慢

我见过有人说每千行代码的bug数在0.5-50个。但是我发现得出这样的结论的人只研究了1-2个成熟的软件项目在某一个时间点或两个版本之间的代码。只查看某个项目在一个时间点的快照，凭什么认为这个项目在早期或后期的情况会保持不变？

根据上述数据，认为bug数和代码行数之间存在任何常量的关系是不明智的。相反，我们应该认识到bug数目增长的速度会随着项目的成熟而越来越慢。原因是了什么？我认为：

我们观察到的频率呈对数分布，而不是正常分布。一小部分bug能被更快、更频繁地发现，而系统中处于“长尾”的bug发现速度和频率要低得多。

bug数量与功能数有关，而跟代码行数无关，而代码行数与功能数呈超线性分布。（随着项目的增长，添加新功能所需的代码行数会增加。）

项目的核心应该随着时间的推移变得更加稳定，因为我们会修复bug，但不会做出重大改变。随着项目的成熟，新来的开发人员不太可能改动关键的代码，而且新功能的开发需要的核心变化更少。

那么哪些不是问题的bug和不是bug的问题呢？

对于这种大小和范围的研究，GitHub的issue是我所知道的记录bug的最佳形式。自动bug检测软件仅适用于某些语言，而且只能检测到“结构性”的bug（比如无效的内存访问），而却无法检测到逻辑错误（例如错误的计算），而且手动统计bug数是不切实际的（或者根本不可能）。我们必须假设处于开放状态的issue能够代表用户遇到的bug数。

异常值和替代假设

在查看这些数据之前，我没有猜到仅靠提交代码的人数就可以预测bug数。这表明项目的开发人员数量蕴含了有关项目的其他大量信息。一种合理的解释是“大型开发团队有向平均数回归的趋势”：即随着团队开发人员数量的增加，项目的提交次数/功能/代码行数与开发人数的比率倾向于一个平均值。

随着开发人员数量的增加，代码行数的范围变窄。

在浏览异常值时，我遇到了一个特别有趣的类别：游戏机模拟器。该类软件拥有测试输入（游戏），测试人员（游戏玩家）和其他实现（其他模拟器和系统本身）等数据，可以为将来的软件bug数的比较研究提供更加可控的实验环境。

【编辑推荐】

1. AI 的主打歌：主的是程序员，打得作曲家神不守舍
2. 从职业方向，谈程序员如何突破成长瓶疾，我们该怎么去学习？
3. 程序员必备开发工具（IDE）推荐
4. 开发者为什么不愿意参与开源贡献？不仅是钱的原因
5. 程序员的发量果然一天不如一天......

（编辑：ASP站长网）