你只看到了一团团杂乱的点，对吧？这就对了：上图证明了代码行数与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数的比较研讨提供愈加可控的实验环境。

【编辑引荐】

AI 的主打歌：主的是顺序员，打得作曲家神不守舍

从职业方向，谈顺序员如何打破成长瓶疾，我们该怎样去学习？

顺序员必备开发工具（IDE）引荐

开发者为什么不情愿参与开源贡献？不只是钱的缘由

顺序员的发量果真一天不如一天......

(责任编辑：admin)