阅读一些论文的收获整理，全是私货(雾)
这篇论文通过整理并筛选了github上的使用了一个名叫Travis CI的java项目，统计CI历史中出现的CE与各项因素的关系
主要遵循了采集数据-分析数据-发现联系-提出解释-给出建议的思路
整个项目的build分为多个过程，build的状态有success, error, fail, canceled和started等，maven和gradle的error和fail分别出现在不同的步骤
最后对developer,tool,researcher各自提出了自己的建议
频率分析
分析了CE频率与项目性质、分支、代码类型(production code or test code)、build state、trgerring events之间的关系
分布分析
作者使用了正则表达式匹配统计各种错误类型，并与google的结果进行了比较
因素作用关系基本同上
fix effort分析
通过分析CE出现到消失的时间来衡量fix某个CE所耗费的effort
- 排除掉了多错误CE，因为研究难度过大
- 排除掉了超过12个小时的fix，因为这可能跟程序员的个人生活安排有关
设计到代码架构实现CE比个别地方写错的CE需要更多的时间fix
google的平均fix时长短一些，可能是因为google对fix时间有要求，而且还有数据集的区别
fix pattern分析
人工分析
Programmers’ Build Errors: A Case Study(at Google)
这篇论文研究了3个问题：
- 编译错误的频率
- 编译错误的原因
- 修复错误编译的时间
方法：一个parser，可以将报错分类
标准
数据来源是build的log file
计算了以下维度的数据：
- 编译次数
- 编译失败率：失败次数/总编译次数
- 编译错误类型
- count-all:一次编译中出现的多个同类错误算多个
- count-distinct:….算一个
- 但是错误出现的次数权重是不对等的(比如漏写一个声明会报一堆符号错误)，所以采用count-distinct比较合理
- 解决时间：第一次build fail结束到第一次build success开始之间的时间，同时记录了这期间build fail的次数
- 只考虑单错误的fail building
- 只考虑在12个小时内解决的错误
RQ1：错误频率
把开发者按照经验分类进行了数据分析
但是对经验程度的定义可能不够准确
RQ2：错误原因
把各种编译错误分成了5个大类：Dependency, Type mismatch, Syntax, Semantic, Other
对于C++和Java来说，Dependency-related error都是最常见的错误类型
RQ3：修复时间
把研究对象限定为单一类型的错误信息，排除多错误修复时间带来的误差
进一步分析，还进行了case study
首先随机选择了25个Java的cant.resolve类型的编译错误，这些错误都是在下一次build的时候就修复了的，对比了修复前后的文件来观察错误是如何被修复的，并将结果记入表格
近期评论