ICSE 2017 Do Developers Read Compiler Error Messages? 阅读笔记

原文地址：http://static.barik.net/barik/publications/icse2017/PID4655707.pdf

1、摘要：

在如今集成开发环境中，开发者们会通过各种各样的形式接收到编译错误的信息，比如：弹出信息、在错误地方高亮红色下划线。尽管报错是编译器向开发人员“表达信息”的一种方式，但我们不知道开发者们是如何理解利用这些编译器提供的信息的。因此，我们让56位来自我们大学（美国的卡罗利纳、华盛顿）的毕业生或在读生，在基于Eclipse平台和Java语言上处理平常遇到的代码问题，并对他们进行眼动追踪研究。我们发现：
1）参与者们会阅读那些报错信息，而要理解这些信息的难度几乎等同于理解源代码；
2）通过阅读报错信息的难度可以清楚地预测出参与者的工作表现；
3）参与者们会分配大概整个工作的13%-25%的精力去阅读理解报错信息。
通过我们实践总结出的经验，可以为改善编译报错信息提供帮助。

2、例子：

Barry根据Eclipse提供的编译报错信息，一步步改进代码：
1）找到出错代码，阅读出错原因
2）选择不同方法解决，例如删除该行或进入到包含这行函数的库文件阅读寻找解决办法
3）选择了其中一种方法解决，但最后结果仍然出错
4）其实是拼写错误

3.方法：

研究问题：

1）开发者们在处理不同类型的报错信息时的效力和效率如何？
2）开发者们会阅读报错信息吗？因为很多时候开发者可以直接通过IDE上双击报错信息跳转到出错代码上直接通过自己的判断处理问题，而不选择去阅读。
3）编译错误会因为报错信息而更难处理吗？因为有时候解决问题只需要对代码一点小小的改变例如修改循环条件防止越界等，但编译器提供的报错信息可能导致开发者很困惑，不知道需要修改什么。

研究设计：

1）参与者：平均编程年龄1.4年，对Eclipse和Java都比较熟悉，平均年龄24岁，46位男性，10位女性。
2）任务：在Google上找到超过2千6百万的包含出错的项目代码，并在各类错误中找到最花费时间的前几个用于实验，然而本文没有权限得到Google中的代码报错信息，作为替代，本文后来使用Apache Commons Collections提供的库，人为在其中添加错误然后用于实验。
3)工具和器材：win8，24英寸显示器，1920x1080分辨率，与GazePoint GP3 眼动跟踪装置连接。之所以选用Eclipse IDE是因为它的问题栏（problems pane）和快速修复提示（Quick Fix popups）是一个亮点相对于其他IDE例如IntelliJ和Visual Studio。

流程：

1）管理：每个参与者需要解决10个源代码错误，每个错误只给5分钟时间解决。我们要求参与者为每个错误给出他们认为最能准确表达代码意图的可解释的解决方法。例如：删除项目中所有的文件可以解决问题，但这明显不是代码的目的。另外，我们不要求参与者能解决所有问题。只要求不使用除了IDE以外的任何工具，例如上网搜索，只能利用IDE的各种特性（快速修复等）解决。
2）校准：在正式实验前调整好参与者的位置、眼动装置的参数等等。
3）实验：参与者不能提问，不会得到他们提交方案的回馈，每人大约花费45分钟时间完成所有任务。

数据收集和整理：

收集参与者的眼动情况。参与者感兴趣的区域有：
1）the explorer pane，用于导航的栏目
2）the outline pane，当前类的方法
3）the problems pane，项目的errors和warnings
4）the source editor，源代码
5）the error popup，当悬停在代码行前时出现的出错窗口
6）the Quick Fix popup，当悬停在错误代码上时的修复方法窗口

4.分析：

1）对于效力评估，使用Apache Commons Collections库提供的单元测试进行评测。将同一任务下仍然出错的参与者们分类，如果他们产生同样错误，那么一定存在一些共有的原因；对于效率评估，使用完成的时间决定。
2）通过比较正确率和参与者将视线集中在报错信息的次数上，来得出难以理解的报错信息是否与难以解决问题有关的结论。

5.结果：

1）
对于解决问题的用时测量（排除超时的），使用t-test，一种用于小样本的两个平均值差异程度的检验方法。得到的结果是错误解决办法用的时候比正确的还要多20秒，这代表了参与者们都是尽力想解决问题的，而不是随便用能最快解决问题的办法来处理的。（实验的有效性）

2）
KL散度，又称相对熵、信息增益，是描述两个概率分布差异的一种方法。用这种方法分别对
[源代码编辑部分，报错信息部分]，[源代码编辑部分，阅读部分]，[报错信息部分，阅读部分]，
（阅读部分是先验工作，事先对参与者的阅读文字速度进行测试得来）
其中源代码编辑部分和报错信息部分的值是最小的且比其他两个小很多，即两者花费的时间是最相近的。再结合Table III，得到参与者们是有使用到报错信息的。

3）
回顾报错信息的次数越多，错误率就越高，表明任务难度与报错信息阅读难度是正相关的。

6.讨论：

1）报错信息不会根据情况适应。

举个例子，将AbstractLinkedList这个父类中的isEmpty()函数删除，则在运行时需要它的子类CursorableLinkedList需要调用到这个函数的时候就会报错：The type CursorableLinkedList must implement the inherited abstract method List . isEmpty ()，另一个子类NodeCachingLinkedList也相同。大多数参与者会根据这个报错信息寻找到两个子类，然后根据文档需求重新补充，而不是找到父类重新补充，因此可以看出报错信息的报错优先级是存在不适应性的。

2）报错信息想要像自然语言一样表达，但实际上这和读源代码一样困难。

原因一：报错信息中既含有代码又有自然语言，如The method get () is undefined for the type Queue ，而切换地理解两种语言需要耗费时间。
原因二：开发者需要边浏览源代码边理解报错信息，思考每一步正确的做法是什么。对于这个原因的解决方法可以是利用LLVM scan-build方法，不用将代码和报错信息捆绑，而是一步步告诉开发者哪里出错，应该如何修改。

3）工具的无法使用。

参与者们有时想用工具来导航到出错的代码，或者想要比较某两个函数，但在编译器中有时会失效或者出现多余的操作提示。虽然我个人认为这个问题不大，但确实有点影响debug时的效率，作者认为编译器可以像Quick Fix popups一样提供一个Quick Understanding popups，以高效处理问题。

7.限制：

1）由于没有得到Google study中OpenJDK的客户数据，实验用的错误类别相对较少，靠自己播种手动生成。
2）眼动追踪装置对戴眼镜的、光照变化效果一般；不能做到对行、词视线的检测。等等。
3）参与者是学生而非全职专业程序员，尽管有相关编程经验但对工业不够深入了解，可能专业人员有独特的debug的操作。

8.总结：

本文作者使用眼动追踪方法在Eclipse IDE上对开发者们是否阅读报错信息进行研究。通过对源代码、报错信息和先验的阅读文字速度的分布对比，作者发现开发者们是阅读报错信息的，但也发现了理解这些信息的难度是和阅读源代码的难度相同的，即认知需求的工作。通过对开发者们的视线测试，作者发现开发者们花费大量的时间在报错信息上尽管大多数任务中报错信息只有寥寥几行。根据开发者们对报错的回顾次数分析，发现是否能成功完成一个debug任务是和能否真正理解报错是有直接关系的。

最后，本文通过公平公正的测量，得出的结果对当下编译器改善报错信息的表示是有参考价值的
。总结起来就是一句：报错表示是非常重要的。