您现在的位置:青年桂航网>> 青年文艺>> 好书分享>>正文内容

“研”磨记

        2006夏,去斯坦福读博前的几个月,我曾思考过我对什么科研课题感兴趣。总体来说,我想开发一些创新的工具来帮助做计算机编程的人们更高产(亦即,提高程序员的生产效率)。其实这个想法源自我暑期实习时自己编程的体会:由于我对日常工作提不起兴趣,我经常窝在公司分配给我的小办公桌前思考,这个公司为什么编程效率如此之低。我想,如果我的研究可以帮助提高编程效率,就再好不过了。更宽泛地讲,我对提高其他计算机使用人员(不仅是程序员)的工作效率非常感兴趣。例如,我想设计一些新工具,帮助分析数据和作图的科学家,定制服务器配置的系统管理员,或者学习软件的新手。

        尽管当时我大概模糊地知道我的研究兴趣,我仍需要几年时间才能把这些兴趣转化为真正能发表的研究项目,以完成最后的博士论文。为了从斯坦福计算机科学系博士毕业,学生们必须以第一作者身份发表2-4篇话题互相关联的文章,再综合起来,写成一本书一样的技术文档,就是所谓的博士论文。若论文评阅委员会(包括三名教授)同意通过这篇博士论文,学生就可以毕业了。在我专业就读的博士生大多数都需要4-8年才能毕业,发表文章快,毕业得就早,反之也就越慢。

        2006年9月新生见面会上,我专业的教授鼓励学生们尽快联系导师。所以最初的几个月里,我和我的同学一直在和教授们交流,试图找到适合自己的导师。这位导师是论文委员会中最重要的一员,并且拥有学生毕业的最终决定权。我的研究领域中,导师们通常从他们的研究经费中拿出一部分发给学生作为工资,他们也和学生们一同做研究,想思路,写文章。我见了一些教授,觉得Dawson的研究兴趣和科研方式貌似与我自己最接近。所以我选择了他作为我的导师。

        我刚入学时,Dawson已经在斯坦福工作了8年,刚刚被提升为终身教授。想拿到终身教授这一职称,并获得终身聘用的保障,教授在大学中工作的前7年里必须发表足够多有名的文章。Dawson的主要研究方向是开发一些新工具,使之可以在实际应用软件的复杂片段中自动找出“bug”,也就是软件代码里的错误。过去十年中,Dawson和他的学生做的几个工具都能比其它竞争对手发现更多的错误。凭借超乎常人的研究技术,他们成功创业,建立了自己的创业公司,销售软件揭错的服务。尽管Dawson的项目多少符合我的胃口,但是我更看重的,是他和我非常相似的研究理念:作为狂热的实用主义者,比起深入证明理论“趣味”从而提高学术地位,Dawson更关注的,是取得引人瞩目的成果。

        我第一次找Dawson谈话时,他好像对我宽泛的想法(提高计算机使用和编程效率)兴趣不大。但是他明确表示,他想用他当时的实验基金招收新生,做一个自动揭错的工具,称为Klee(这个工具有好几个名字,简洁起见,我还是叫它Klee)。我向系里其他教授和高年级博士师兄师姐都取经后意识到,新生加入一个已有的项目是科研惯例,通常情况下,新生不会马上自己立项著说。我告诉自己,软件自动揭错的研究对我来讲是曲线救国,因为这项研究同样可以使程序员更有效率。就这样,我决定了加入Klee项目。

        2006年12月,我开始做Klee。那时Dawson在同时指导其他五名学生,他们参与这个项目已经有了一段时间。项目负责人Cristi是一名博三学生,他和Dawson一起开发了Klee的第一版。Dawson、Cristi和一些其他的同事已经合作发表了第一篇关于Klee的文章,描述最基本的Klee系统,演示Klee寻找新错误的效率。这篇论文在学术圈里广受好评,Dawson也想保持好苗头,通过发表一系列后续文章继续延伸这个项目。注意,只要有新想法新结果,对已发表的文章有所改动,用一个研究项目是可以发表多篇文章的(即后续文章)。当时的下一个相关学术顶级会议的截稿期限为2007年3月,Klee团队有四个月的时间在原始文章的基础上创新,以取得发表会议论文的机会。

        继续讲故事之前,我想要简要地介绍一下学术论文的评审和发表过程。在计算机科学这一领域中,学术威望最高的发表平台是学术会议。请注意,许多其它领域中期刊文章的学术威望最高,“会议”这个词的含义也很不一样。现在我对计算机科学学术会议的发表过程简单介绍如下:

        1.      会议发布征稿通知,涵盖感兴趣的研究主题,并指明截稿日期。

        2.      研究者需在截稿日期前提交文章。一般一个会议会收到100-300篇文章,每一篇文章的篇幅相当于30-40页双栏文本的长度。

        3.      会议的程序委员会(PC),也就是20位左右的专家,每个人会分到一些文章进行审阅。每篇文章会被3-5位专家阅读,他们要么是PC成员,要么就是PC成员另外遴选的义务评审。评审通常需要3个月时间。

        4.      委员会审完所有文章以后,聚在一起依据评审意见决定每篇文章录用与否。

        5.      委员会给作者邮件通知评审委员会的决定,通知邮件中通常会附加书面评审意见。

        6.      录用文章的作者参加会议,发表30分钟的报告。所有录用文章随后会被打包上线,上传到数字图书馆。

        有学术威望的顶级会议录用率大概在8%到16%之间,二级会议录用率则大概是20%到30%。通常来讲,这些会议的录用率都较低,所以退稿,修改,再提交同一篇文章并不稀奇。加之一篇文章一次只能投到一个会议中,这个过程甚至可能花上几年时间。

        Dawson清楚表示,要赶在2007年3月那个顶级会议的截稿日期之前写出一篇论文。他还告诉我其他五个同学的分工情况和我可以立即上手的任务。我选择了使用Klee来寻找Linux设备驱动中新错误的任务。所谓设备驱动,指的是一种允许操作系统与硬件设备(如鼠标或键盘)进行通信的代码。Linux操作系统(与微软的Windows或苹果的Mac OS类似)包含数以千计的设备驱动,以与各种不同的硬件设备相连。设备驱动代码很难用传统方法揭错,而且这些错误包含潜在危险,可能导致操作系统停止响应,或者崩溃。

        Dawson相信Klee可以在数以千计的Linux设备驱动的代码找出新错误,那些用已有的自动或人工方法根本找不到的新错误。我记得当时我暗自思忖,对新的Linux设备驱动揭错并成文发表是挺酷的,但我不明白,这些成果如何能对学术领域做出真正的贡献。我总觉得,用Klee找到新的错误只是现有程序的应用,并没有对Klee进行创新革命。此外,我不明白,我的项目怎么能和其他五个人的项目放到一起,整合成一篇连贯的论文,在三月提交。然而我相信Dawson一定有高深的文章写作策略。鉴于我刚刚进组,我可不愿意立即质疑这种教授级别的决策。既然他给了我一个具体任务,我尽我最大的努力完成它就好了。

        读博生涯的前四个月中,我一直在精心刻苦地让Klee研究成千个Linux设备驱动,试图找出新的错误。这任务尽管从概念上看比较简单明了,但是实施起来,不尽如此。让Klee研究设备驱动的过程中需要注意的细节数量浩大、错综复杂,令人目不暇接。我经常花费好几个小时设置好一个脆弱的实验条件,好让Klee分析某个给定的设备驱动。这一番功夫后,我却又只能看着Klee因为自身代码中的错误崩溃失灵,十分无助。我向Cristi报告Klee里的错误,尽管他尽力寻找,但Klee实在太复杂了,也很难诊断并修复其中的大多数错误。注意,我并没有单指Klee,因为任何以研究为目的而开发的原型软件都会有很多不可预知的错误。为了用Klee在Linux的设备驱动代码里揭错的我,到最后却只能找Klee程序它自己的错误,真是非常讽刺(为什么Klee不能自动在自己的代码里揭错?!)。时间一天天流逝,我也越来越沮丧:我觉得自己变成了想办法让Klee能用起来的小工,我的苦力劳动根本没有任何技术含量。

        我平生第一次被分配到的任务完全击倒,绝望不已。在这之前,我通常可以掌控暑期实习中的任务;虽然大学里的很多作业都很有挑战性,但那时总还是有正确答案待我寻找。如果不理解课堂中的某个知识点,助教和高年级学生都可以辅导我。本科期间,即使我在科研,也可以经常可以求助于我的学生导师(一位博四学生),因为我研究的问题相对简单,他通常知道如何解决。本科生助研对科研也不会那么重视,注入精力较少,因为在当时,科研只是我日常工作的一小部分。被某个研究问题卡住了的话,我就做作业或者和朋友出去玩,转移注意力,毕竟大学毕业并不取决于取得优秀的研究成果。然而在读博士研究生时,研究是我唯一的工作,没有优秀的研究成果,就拿不到学位。于是我的心情完全和每天的研究进展紧密相关,而在那些日子里,研究进展真是慢得让我痛苦。


【字体: 】【收藏】【打印文章】【查看评论

相关文章

    没有相关内容