怎样才能减少软件中的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. 措施员的发量公然一天不如一天......

（编辑：河北网）

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