Ph.D.攻读期间的规划与执行

（出自我为我们实验室撰写的内部资料，因感觉很有用，故在此留存）

很好，我现在有了一个绝妙的idea，现在就差把它写成论文发表在顶会上了！这篇文章会拿到Best Paper，然后会让我走向人生巅峰……慢着，请停一下你的想peach行为，仔细思考思考这个idea与一篇好的研究工作之间还有多大的差距。要填上这个差距并作出卓越的研究，我们可能需要聪明的头脑、缜密的计划、钢铁般的执行力、和一些运气。事实上，在历史上的接近时间点往往有很多研究者产生了类似的研究想法，但是最后真正成功做出结果并被后人记住的往往只有一到两个。这告诉我们，有一个好的规划与执行的策略是非常重要的。虽然笔者水平有限，经验不足，不过深感执行力的重要性，因此试图在这里分享一些浅薄的见解与经验。

制定研究Protocol

首先，你的研究的想法不能是过于粗略的，最好是能细化就细化。对于实证研究而言，往往是需要细化到能够回答如下问题

1. (Motivation) 为什么需要这个研究？他对软件开发的帮助在哪里？
2. (Related Work) 你的研究与已有研究相比的核心区别在哪里？
3. (Research Question and Methods) 具体有哪些研究问题，每个研究问题采取什么方法来回答？

当你有了这样的一个Research Protocol，可以去找比你有经验的人去讨论，有经验的研究者往往能有一些sense和intuition能判断这个问题是否值得做，也能看出一些需要解决的问题。如果大家都觉得这个protocol是一个好的研究protocol，那我们就可以考虑去做了。否则，往往还需要去阅读更多文献，与工业界交流或者参与/观察软件开发，来思考更好的研究protocol。

规划你的研究

从规划的角度，不同的类型的研究也是需要不同的策略的。因此，首先需要明确你的研究属于什么类型，并针对你的类型制定合适的策略。

有一类研究是这样的，这个研究的想法可能来源于某种偶然的突发奇想；它的视角可能新颖而有趣；主题可能是针对某种新兴事物；可能想到这个想法并没有那么容易；但是写完了论文再看，观察和分析的视角看起来是朴素而任何人都能想到的。有人将这一类研究叫做“突发想法”类研究，而我则倾向于将其命名为“快枪手”类的研究。虽然这些研究的视角非常新颖，但是做起来的难度可能没那么高，任何人都有可能想到去做这个研究。在软件工程领域常见的一个实证研究的pattern就是，一个新的工具/流程/系统出现了，我们就去调研和总结一下这个东西的使用情况，发现一些改进点。比如说，GitHub推出了Dependabot，有人就赶紧去总结一下Dependabot[1]的使用情况；又例如说，深度学习很火，那我们就赶紧总结一下开发者在深度学习上遇到的困难[2]；等等。在技术文章上也会有类似的情况，当你发现了一个有趣的技术问题时，需要赶紧定义这个问题并提出一个解决方法。对于这种研究，一旦这个主题被人做过了，你要再发一篇文章就会很难，需要做出显著的增量成果（因此往往就会落入后面提到的两类研究范畴）。因此，如果你产生了类似的研究想法，你需要去尽快地将这个研究实现出来，做那个“第一个吃螃蟹”的人。最好的规划方法是面向一个合适的顶会DDL，先搞一篇文章投出去再说。

另一类研究是这样的，这个研究的想法可能已经并不是那么新颖了，相关的研究可能有很多，但是大的研究问题依然并没有得到很好的解决，需要有人接着把这个研究方向往前推，但是往前推进并不是很容易，需要对问题的特性和已有研究做出全面与深入的了解。有人将这一类研究叫做“系统性”研究。值得一提的是，关于一个研究方向到底还需不需要新的研究，也就是这个方向有没有死，是个更加困难和难以判断的问题，在这里不做讨论。这一类研究就不是想法取胜了，而是需要有非常扎实的执行过程和独特有趣又扎实的技术方法。

最后一类研究是这样的，这个研究的主题已经有段时间没有人做过，近年的相关文章很少，虽然也许问题的价值很大，但是似乎是不怎么做的下去了。有人把这一类研究叫做“难题攻关类”研究。还是一样的，关于这一类课题到底还要不要做的问题不在本文的讨论范畴，不过显然，为了你身心健康，我只建议当你在毕业无忧的时候选择这一类问题去攻关。

对于最后两类研究而言，最大的陷阱就是时间陷阱，因为你需要花一个很长的时间周期去做这个题目，很容易就天天摸鱼，把时间和精力都浪费了。如果因此还造成了巨大的身心健康问题，那更是得不偿失。因此，对于这两类研究，需要有明确的阶段性产出，例如首先要有文献调研，然后要分析问题的性质和难点，最后是多轮的解决方案迭代。期间，如果有中间成果，也是可以考虑发表的。第一轮的发表对应Literature Review/Synthesis，第二轮的发表可以是Empirical Study或者Experience Paper，等等。

最大化工作效率

之前提过，Ph.D.最大的陷阱之一就是时间陷阱。科研是一个漫长且反馈周期很长的持久战，就好像跑马拉松，需要一些习惯来保证自己的日常工作效率，从而确保自己能够有足够的产出。

最大化工作效率的前提条件是，拥有健康的身体和积极向上的心态来对待你每一天的科研工作。笔者在这方面也不是什么专家，但也可以有一些小的建议。

1. 对你的研究计划和阶段性结果有文档记录
2. 每天制定一个小的目标去完成
3. 尽可能利用碎片化时间来思考你的问题
4. 尽可能创造出一种“心流”的状态
5. 清楚自己的身心状态并且做出合理规划，该肝就肝，该摸鱼就摸鱼

此外，为了最大化工作效率，精通你手里正在使用的工具也很重要。很可惜的是，国内的计算机本科教育极大地忽视了这一点。笔者至今还记得自己的大一编程课老师在课堂上说：

工具什么的不重要，北大的学生都这么聪明，你们课下自己去学就行了

真是误人子弟。靠自己自学野路子成材的人可能有，但是更多人可能就陷入迷茫之中，从一开始就没有掌握很多应该掌握的技能和习惯，长远来看对个人发展非常不利。笔者见过不少人，到了研究生阶段还在以一种令人震惊的低效方式工作，而这很容易让自己陷入重复性工作的烂坑，极大地影响了工作效率和产出，甚至导致一个研究项目最后啥也做不出来。在这里笔者极力推荐MIT推出的面向大一新生的一门非常简单但是无比有用的神课：The Missing Semester of Your CS Education，专门系统性地教你如何利用常见的计算机工具最大化你在计算机领域进行相关实践（be it engineering or research）的效率。

注重可复现性

令人遗憾的是，软件工程领域的研究者自己往往甚至都不能让自己的研究项目遵循软件工程的最佳实践。太多的论文最后发布的代码就是一坨屎，既不知道里面藏了多少Bug，也不知道114514年后到底还能不能再运行了。甚至有些论文，明知自己的代码有些地方可能不太对，也不去管他，赶紧把文章发出去了事，最后坑害了想要follow的人。所幸的是，现在越来越多的高质量会议都开始要求论文的透明性和课复现性，并要求提交相应的Artifact。

会议往往会对Artifact的质量标准提出明确要求。这里引用ESEC/FSE 2021对Artifact的要求：

• Artifacts Evaluated - Functional: This badge is applied to papers whose associated artifacts have successfully completed an independent audit. Artifacts need not be made publicly available to be considered for this badge. However, they do need to be made available to reviewers. Two levels are distinguished, only one of which should be applied in any instance. These artifacts need to be:
  • documented: At minimum, an inventory of artifacts is included, and sufficient description provided to enable the artifacts to be exercised.
  • consistent: The artifacts are relevant to the associated paper, and contribute in some inherent way to the generation of its main results.
  • complete: To the extent possible, all components relevant to the paper in question are included. (Proprietary artifacts need not be included. If they are required to exercise the package then this should be documented, along with instructions on how to obtain them. Proxies for proprietary data should be included so as to demonstrate the analysis.)
  • exercisable: Included scripts and / or software used to generate the results in the associated paper can be successfully executed, and included data can be accessed and appropriately manipulated.
• Artifacts Evaluated - Reusable: The artifacts meet the requirements for the Artifacts Evaluated - Functional level and in addition they are of a quality that significantly exceeds the requirements set for the first level. Authors are strongly encouraged to target their artifact submissions for Artifacts Evaluated - Reusable as the purpose of artifact badges is, among other things, to facilitate reuse and repurposing, which may not be achieved at the Artifacts Evaluated - Functional level.

我个人的建议是，不要等到最后一刻再尝试去满足这些要求，而是最好再项目创立的伊始，就好好遵循对应技术的软件工程最佳实践。虽然也许这样一开始会很麻烦，但是研究项目不是课程项目，你可能需要花几个月甚至超过一年的时间来反复维护同样的代码，而往往研究项目会涉及非常复杂的代码，因此当你做的项目越来越复杂的时候，你往往就会感受到软件工程带来的好处了，并且可以提升长远来看的工作效率。

此外，在做实验的时候，最好能够尽可能将所有的流程自动化，使用参数来配置代码，避免复制黏贴，并按照有迹可循的方式保存做实验需要的所有参数和输出结果（例如，shell脚本和日志文件），便于最后一刻反复微调实验，加快迭代速度，也可以提升文章的可复现性。

风险管理

任何研究都不是没有风险的。事实上，做研究可能是世界上风险最大的事情之一了。你的研究可能会有结果不符合预期，可能一开始设计的方法根本就不work，可能结果完全无法用你的理论解释，这一切都是完全正常的。在做规划的时候，从一开始就要拥抱变化并快速迭代，才能有比较好的结果。

参考文献

1. Alfadel, Mahmoud, et al. “On the Use of Dependabot Security Pull Requests.” 2021 IEEE/ACM 18th International Conference on Mining Software Repositories (MSR). IEEE, 2021.
2. Zhang, Tianyi, et al. “An empirical study of common challenges in developing deep learning applications.” 2019 IEEE 30th International Symposium on Software Reliability Engineering (ISSRE). IEEE, 2019.