以下为译文:
怎样才能增加软件中的Bug?本文将通知你传统观念是错误的,下列数据会让你感到诧异。
软件开发人员普遍以为,代码量越大Bug就越多。虽然许多人并不是很清楚这两者之间确实切关系,但他们以为二者是线性的关系,即每千行代码中的Bug数与代码量成正比。但是,依据对GitHub中最受欢迎的10万个代码库的研讨发现,代码行数与Bug之间并不存在这种恒定的关系。而且,代码行数并不是Bug数的牢靠目的。
注:在本文中,我用“bug”来指代软件中从一些从用户的角度来看的异常行为,例如:死机、视觉异常、不正确的数据等。“Bug”也常用于描画软件中可应用的缺陷,但这是从攻击者的角度来看。本文不触及安全破绽,由于安全破绽能够需求别的模型来剖析。
相反,我们发现了两个更牢靠的目的:贡献代码的开发人员数量和提交代码的次数。本文中的图片运用了一个拥有两个变量的模型,而且这个模型在预测Bug数目时,与我另一个拥有16个变量的模型表现简直相反。我会详细解释这些模型的建模进程,但是首先:
假设存在这种因果关系,那么这对增加Bug意味着什么?
假设你需求牢靠的软件,那么请不要运用会产生Bug的办法论。例如,矫捷主张直接写代码,然后经过迭代这些代码来优化需求,所以会产生很多提交(而提交次数与bug数毫不相关)。
原型可以增加bug,但是你必须在运用完后丢弃这些原型。你需求经过数次提交来学习技术和客户的需求,然后编写一个非原型版本,其中包含更大批的提交次数和/或更小的团队。
刻意保障系统牢靠性的任务能够会产生相反的效果。在采用测试驱动的开发和单元测试的状况下,假设提交的代码次数,或需求的开发人员的话,那么bug数也会,这能够与你的直觉恰恰相反。
关于团体而言,你应该将时间破费在写代码之外的事情上,例如思索、设计、和制造原型等等。
关于企业而言,雇佣的开发人员数量越少越好,当然开发人员的阅历越多越好。
搜集数据
首先,我经过GitHub API,查询了10万个最受欢迎的项目(超过135颗星的项目)。这些项目并不是随机抽样,它们占据了GitHub上最顶级的0.1%,所以我们愈加自信会有很多人发现和报告bug。关于每个项目,我提取了项目的创立日期(GitHub上的日期),给星数量,成绩数量,提交PR的次数,以及issue tracker能否被禁用。
接上去,我克隆了一切非私有的代码库,并直接从Git和文件系统搜集了以下统计信息:
最后,我针对每个代码库的HEAD信息,搜集了Tokei的统计信息:每种检测到的言语的代码行数、注释、空格等等。然后,关于每种Tokei检测到的言语,我计算了总字节数和LZMA紧缩后的字节数。
排名前50的总代码行数。被扫除的言语(文本和标记)用灰色显示(Text、Html、Markdown、Sg、ReStructuredText)
控制受欢迎度等差异
我们以为,旧项目和受欢迎项目的平均bug数会更偏高。为了控制这些差异以及其他差异,我运用了如下模型:
ln(issues) = β1created age + β2first commit age + β3ln(stars) + β4ln(contributors) + β5ln(all commits) +β6ln(code) + β7ln(comments + 1) + β8ln(pull requests + 1) + β9ln(files) + ε
我经过这个模型做了拟合,并经过10折交叉验证测试了模型与线性回归的拟合度,然后在一个组合图中绘制了每个折叠的预测误差。在此之前,我删除了一切私有、归档、镜像和分叉项目,没有启用issue tracker的项目,以及数据集中bug数为零的项目。
9个变量模型的预测误差
这个模型有一些偏向,但其他方面的拟合度还不错。它高估了GitHub上成绩数量很少(<10)的项目的bug数(相反低估了成绩数量偏高的项目)。我疑心这是由于github的api中没有将分叉项目的记出来,还有一些包含第三方代码的项目招致的。这些项目夸张了与issue>
ln(issues) = β1ln(code) + ε
ln(issues) = β1ln(lzma bytes) + ε
仅包含代码行或lzma紧缩的代码字节的模型(阐明了言语之间代码密度的差异)表现异样蹩脚。
用9个变量的模型拟合残缺的数据集后,得出了以下近似值:
ln(issues) = 0.022created age – 0.017first commit age + 0.315ln(stars) + 0.071ln(contributors) + 0.266ln(all commits) +0.072ln(code) + 0.034ln(comments + 1) + 0.413ln(pull requests + 1) – 0.069ln(files) – 1.690
我们可以看出,模型中的主导变量是PR数(0.413)、给星数(0.315)和提交次数(0.266)。将这二者与代码行数(0.072)和注释(0.034)相比较,就会发现这些差异愈加清楚,尤其是再思索到变量尚未标准化,而且简直一切项目中代码行数都会高于PR数、给星数或提交次数。
由于PR数和给星数是GitHub特有的功用,我还构建了一个没有这两个数据项的模型。然后,依据拟合模型的系数,再进一步将其简化为只包含提交代码的人数和提交次数。这种只要3个变量的模型的表现简直与其他模型完全相反,而且还可以显示成3G图形:
ln(issues) = β1first commit age + β2ln(contributors) + β3ln(all commits) + β4ln(code) + β5ln(comments + 1) + β6ln(files) + ε
ln(issues) = β1ln(contributors) + β2ln(all commits) + ε
在删除了GitHub特有的数据项后,提交代码的人数和提交次数就占据了主导位置,从删除一切其他变量时错误数细微的增加就可以看出。
会不会是这个模型搞错了?
如今我们知道了提交代码的人数和提交次数的影响,下面我们来看看,假设不采用任何依据提交代码的人数和提交次数绘制图形的模型,那么代码行数与成绩数量之间有何关系。
针对GitHub上最受欢迎的项目,绘制代码行数(x轴)与GitHub上的成绩数(y轴)的关系图,并依据提交代码的人数和提交次数分组。
为了节省空间,我没有显示一切的10万个顶级项目。我按照提交代码的人数和提交次数停止了分组,由于我觉得这种分组方式最有意思,且最具代表性。为了避免选择偏向,我只在选择分组之后停止绘图。
(责任编辑:admin)