怎样才能减少软件中的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数的比较研究提供更加可控的实验环境。 【编辑推荐】
点赞 0 (编辑:我爱故事小小网_铜陵站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |