研究与编程

开学之后一直就非常的忙。尤其是最近的几周过得都特别的辛苦。基本上是周一开始赶research，周一周二晚上都睡得很少，然后周三中午和导师Meeting。Meeting完毕了之后就开始赶功课，一直赶到周日。这个学期有两门课，一门课巨难无比，另一门课虽然不难但是每周都有作业，也很耗时间，这样留给research的时间本来就减少了。最近又从Robot Control的项目转到了Cyber Security的项目。新项目开始一时无从下手，也走了很多的弯路。

虽然每周开始的时候会弄一下research，这是这几个星期的进度都不好，也没有做出导师需要的结果，每次meeting完了都看得出他比较失望。其实我的导师人很好，也不push，周围的师兄们也过得都挺好的，一周做两三天research应该是足够了的。

觉得其实是造成我现在很辛苦的原因是自身定位的偏差。因为我很明确毕业了之后会进工业界，所以我更加看重开发能力，而不是发表论文。而且我本人也很喜欢编程，所以我总是会深深的陷入到“编程思维”中去。

每当遇到一个问题，我的思维总是围绕这“程序”展开的。使用面向对象还是面向过程，什么样的抽象层次，什么样的数据结构。但是研究其实需要着眼的是理论和方法，而不是程序。

比如说是在做Robot Control的项目的时候。前面学生的代码丢失，我需要重新编写代码。我没有使用我已经很熟悉的Matlab，而且转而使用我不太熟悉的Python，因为Python有更好的执行效率，扩展性和对于面向对象更好的支持。这导致我浪费了很多的时间去熟悉Python的语言特性。

在编写的时候我下意识的将它作为一个应用程序程序来写，分离出了仿真的部分和实际控制的部分。这样只需要对控制部分做少量的修改就成为一个真正的控制器呢。同时还考虑了以后的可扩展性，为以后增加功能都留足了空间，这导致了过份复杂的抽象，代码量也随之增加。我没能在预计的时间内完成。

而到了Cyber Security这个project之后也出现了同样的问题。导师让我在一个只有十个节点的网络里面验证一种方法。因为节点数目很少，我完全可以手动写配置文件，也不过五六十行的样子。但是我却首先去写了一个配置文件自动生成程序，这样可以自动生成大规模网络的配置文件。然后用这个配置程序去自动生成配置文件。这个程序浪费我很多的时间，从周一写到周二的深夜才写完，留给仿真对比的时间很少。最终的结果是我虽然做出了结果，但是实在没有时间去写一篇Well-Documented Report，只好打印出几张图片就过去了。在和导师讨论的时候，导师也不关心这个是自动生成的还是手动生成的。而是着力问我模型上面的问题，和结果的解释，这部分我却没有怎么花费时间。最后的结果可想而知呢。

这些做法都是没有问题的，事实上，这都是一个良好的“程序员”应当考虑的。但是问题的关键是作为“研究者”的导师并不关心这些问题，他需要的是在特定的场景下能够得到合理结果，并且有良好的解释，这些才是可以发表的。即使这些代码离开这个场景就不能运行也无所谓，因为论文里面也不会去讨论这些。

事实上，随着我转换项目，我在Robot Control前期花费大量时间做出最终都付之一炬。因为我基本上再也用不到了这些代码了，根本不需要扩展的程序考虑可扩展性有什么意义呢？而Cyber Security项目中，很有可能可能导师明天就换了idea和model，那个自动生成配置文件的程序可能就可以直接丢到回收站里面呢。

以前就听说过，做研究和做开发是有天壤之别的，现在有了切身的体会。在工业界做开发碰到的基本上都是老问题，而且问题都是会被经常碰到的。所以代码是一种产品，需要反复的打磨和抛光。而在学术界则不同，研究人员的产品是新理论和新方法，程序不过是验证这个方法的一个手段。研究人员需要的是提出想法，用最短的时间去编写程序验证，然后再提出新的想法。所以学术界的程序都是”throwable prototype”。这也是为什么在工业界有嘲笑烂代码的说法叫”University Code”。

以一个开发者的心态来做学术肯定不是一个明智的选择，这样会导致大量的时间浪费，这也就是我这么累的原因。但是由于我以后肯定不会留在学术界，我也不可能仅仅走学术路线。我想我应当做的是将两者分开。研究的时候就应当摆正研究心态，如果有空闲再用课外project锻炼开发能力。

最近读到一篇叫<Software is not science>文章，讲的也是这个问题，读完之后很有启发，也在这里一并分享吧。

http://matt-welsh.blogspot.com/2011/11/software-is-not-science.html

王晶
二零一一年十一月三日夜