加入收藏 | 设为首页 | 会员中心 | 我要投稿 我爱故事小小网_铜陵站长网 (http://www.0562zz.com/)- 视频终端、云渲染、应用安全、数据安全、安全管理!
当前位置: 首页 > 运营中心 > 建站资源 > 优化 > 正文

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

发布时间:2019-05-07 10:32:38 所属栏目:优化 来源:弯月编译
导读:副标题#e# 代码的 Bug 到底与什么有关?代码的行数?项目的规模?还是开发者的人数?在本文中,将基于机器学习模型绘制的图形,告诉你诸多 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. 程序员的发量果然一天不如一天......
【责任编辑:张燕妮 TEL:(010)68476606】
点赞 0

(编辑:我爱故事小小网_铜陵站长网)

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

热点阅读