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

你只看到了一团团杂乱的点，对吧？这就对了：上图证实了代码行数与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. 程序员的发量果然一天不如一天......

（编辑：东莞站长网）

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