《博士磨砺》&The Ph.D Grind （九）

http://blog.sciencenet.cn/home.php?mod=space&uid=659466&do=blog&id=615675

因为之前看的那个博主翻译到一点就没有后文了。正好自己英文阅读水平奇差，有空的时候继续翻译一点，从他翻译的之后开始，故起名为（九）。

//---------------------------------------补充The Ph.D Grind电子版原文链接----------------------------

链接: https://pan.baidu.com/s/1zsZxldsVCm4oPazifgmjTw 密码: 6bk6

//-------------------------------废话结束分割线----------------------------------------------------------

斯科特研究的领域叫人机交互（Human-Computer Interaction）。与其他研究领域不同，人机交互领域的核心算法研究需要人的参与。下面列举了人机交互课题研究的一般流程：

1、观察人类如何解决自身真正关心的问题。

2、设计新的工具去缓解上述问题。

3、设置实验去评估该工具是否真正意义上帮助了人类。

因为我想创造一个工具去帮助程序员实现批量化的代码，所以斯科特建议我去观察一些程序员在工作中由于个人习惯而导致的问题。斯科特特别关注的点在于，现代程序员在编程时是如何大量的依赖网页上各种语言以及粘贴复制程序片段的。在几十年前，关于批量化代码的技术工具都建立在假设只有一种单一程序语言的同质环境中，现在看来这种假设已经非常过时了。只有了解到现代程序员真正面临的问题，我才有可能设计出适应于他们需要的新工具。

既然斯科特提出了更高的要求，我开始去寻找一些可以在工作时间允许我观察的程序员。首先，我尝试从谷歌的高层入手，因为我刚刚在那里任职不久并且我的前任经理同意将我的征集邮件发给他的同事。我很快收到了几封礼貌的拒绝邮件，因为没有人愿意承担可能由于让一个非在职人员查看代码而引起的知识产权问题。然后我给我的一些就职在斯坦福的创业公司的朋友发了邮件，幻想着他们不会受到像大公司一样的约束而拒绝我。不幸运的是，由于商业竞争，他们对开放代码具有更少的包容性。而且他们比在大公司相同岗位的职员更忙也不愿意分出精力来陪一个在读博士来实现他的科研幻想。

我最后做出的尝试是打算去观察在Mozilla（一个开发了火狐浏览器的非盈利组织）的程序员。因为Mozilla的工程软件是开源的，所以我指望着他们不会拒绝一个外人观察他们工作。这一次我没有选择给对方发邮件（我根本不知道发给谁！），我决定开车到Mozilla的总部走到门前去咨询他们。我在公司门口向我遇见的第一个人打了招呼并做了自我介绍。他热情的介绍了他自己并给了我两个可能对这个课题研究合作项目感兴趣的高层人员的邮箱。我很快给两个地址发了邮箱并且惊喜的得到了一个回复，但是遗憾的是他只回复了我一次，从那之后我再也没有收到过这个人的回复。

回想起来，我并不为自己的经历而感到受挫，因为我并没有为在职的程序员提供任何福利，反而我的存在很可能打扰人家的正常工作。幸运的是，几年后我被允许观察另一批程序员工作（也是一个非营利组织），他们是由一批毕业生组成并为科学研究写代码。我荣幸得被欢迎观察他们写代码并可以和他们交流编译环境，这也直接为我的课题研究带来了冷感和启发。

由于从在职程序员那里连连失利，我打算去斯坦福寻得机会。当我从传单上得知我们系里要举办历年来举办的电脑程序大赛时，我立即给组织者发送了邮件。我表示希望在比赛过程中观察学生们编程，他立刻答应了我。

虽然学生们之间的竞赛并不能真实反映当时的编程环境，但至少好过没的可以观察的处境。乔，是斯科特的博士生，他比我大一届，表示也想来观察这场竞赛。我和乔花了周六整整一个上来观察这场持续了四个小时的编程竞赛。这这是一个比较无聊的工作，并且直到最后我也没有从我标注的笔记上学到太多的东西。有了这次经历，我们打算进行更加可控的实验室研究。

出于上面的考虑，斯科特让我和乔组织起来创建一个实验室一起学习而不是单独的做各自的课题。至此我和乔可以彼此分享关注的相同的兴趣点，而斯科特也可以通过参与我们的实验室而减少对我们的管理。我很乐意让乔担任我们实验室的室长，这样我可以同时进行和道森的另一个项目。

我，乔，和斯科特设计了一个实验室课题，让斯坦福的学生花两个半的小时通过抓虫编写一个基于网页的聊天室。他们可以使用任何资源，包括网上已经存在的代码或者教程。我们招收了20个同学作为实验参与者，他们很大一部分来自斯科特正在教授的走近人机交互课程上的同学。

接下来的几个星期，我和乔坐在我们系里的基层实验室通过摄像头观察了近50个小时（20人*2.5小时）的学生们编程。一开始我们很有热情但慢慢变得枯燥无聊同时我们发现同样的错误行为一次又一次发生。我们更是花了大量时间反复查看录像并标记出错的节点。通过分析记录我们得到了一些关于在哪些情况下同学们甚至现实生活中程序员们在面对简单任务时容易犯的错误。

我们将通过实验得到的发现写成论文并投到人机交互领域的顶级会议上。三个月后，我们得到消息，论文被接受并且被提名为最优秀论文。在这篇论文上，乔是第一作者，我是第二作者。几乎所有的计算机科学论文都是多人合作完成的，并且其作者的排序非常重要。论文署名为第一作者的人应该是在工作中处于领导地位并且比其他人的贡献都多也是最应该得到最多的赞誉的人，其他署名作者都是项目的协助者，往往是年级较低或者远程协助做了足够称得起能署上名的工作的人。博士生通常将导师列为最后一个作者，因为导师启发学生创造出新的想法，协助工程计划以及指导论文。

因为我不是论文的第一作者，所以它对我的毕业没有太大的帮助，但是这次经历教会我非常重要的两点：如何做研究以及如何写论文。最重要的是这篇论文发表在了声望很高的顶级会议上，而不像我博一写的那篇关于Klee的论文，它一开始就被尴尬的拒绝了。

以这篇论文作为毕业课题的开端，乔沿着我们研究的方向继续做了下去。几年里，乔针对我们最初在实验中发现的问题编写了几个工具来帮助程序员解决那些问题并且在几篇发表的论文里描述了那些工具。同时，斯科特没有再主动得联系过我叫我做他的学生，所以我并没有在真正意义上换导师。貌似我和乔感兴趣的点太相同，并且乔已经在他的领域里做出了成就。所以我开始把主要经历放在了道森的项目上，毕竟他才是我真正意义上的导师。尽管进展不会像之前那样顺利也要迎面而上。

回想博一那一年，我做过叫做经验软件管理领域的研究，尤其是通过分析软件项目的发展来提升软件的性能。结果道森也对这个领域感兴趣，所以我们又在一起工作度过了我的博二生活。道森的主要兴趣点在于设计一个自动寻找bug(致使程序出现异常的错误)软件（比如Klee），但是他最终的目的是在总体上提高软件的质量。他反复思索研究着以下几个问题：

1、在一个工程很大（比如有几千万行代码）的软件中，哪几部分对于这个项目来说是至关重要的，哪些部分又不是那么重要的呢？

2、哪一部分或者哪一方面的代码最容易出现错误？比如说，是否近期被新手们修改过的代码更容易出现错误？还是说在短期内被很多人修改过的代码更容易出现错误？

3、如果一个自动检测bug的工具检测出1000个可能存在的错误，那么哪一些才有可能是重要的？程序员不可能有时间精力检查这样1000个bug中的每一个错误，所以它们必须拥有优先级的排序。

通过分析Linux系统内核工具反馈的数据集我在寻找上述问题的答案。我选择Linux系统作为我的研究对象是因为它是当时最流行的开源软件，在那一二十年里，有成千上万的程序员自愿往该项目里写了数千万的代码。并且Linux系统的历史版本都可以在网上找到，所以它成为了我的研究的最主要的数据资源。一个工程的历史版本记录了其整个生命周期，它包含记录了在某个时期人们对其的哪个部分做了哪些修改，最重要的是，它记录了是谁做了这些修改。为了便于研究bug的产生，我从道森那获取了自动获取bug软件在Linux系统中抓取的2000个错误。当然他们不仅仅来源于Linux系统，但目前它们是我的研究可以获取到的唯一资源数据。

我的日常工作包括在linux系统的历史版本和那2000个bug中写代码去梳理、分类、重构和分析信息。