|
在路的篇幅里，我阐述了大量读研时失败项目的例子。
为什么我们的项目做起来总是这么吃力，很多看似简单的项目经常胎死腹中，貌似进展很快的项目到最后迟迟不能结束，针对客户频繁变动的需求程序员们都显得如此疲惫不堪，原来的代码自己都懒的阅读，修改一处BUG引来无数新的BUG，更改（添加）一个功能可能只有几行的代码量，为什么发布上线却需要几个小时的工作量，为什么上线后，甚至一年后都会发现很多BUG,这些问题一直困扰着我，在经历了一些项目的实践之后，我开始总结与反省，阅读了许多书籍，试图从中寻找到答案，其中包括：人月神话，程序员修炼之道，测试驱动开发，极限编程、设计模式等，这些软件工程的书籍清晰的回答了这些问题，极大地丰富了我的眼界。 首先，在我们的开发中，我们远没有一支稳定的开发队伍。对研究生来说，开发的优先级不是最高，经常因为课程、论文或者其他工作被迫从开发的场景里给拉出来，甚至还有一些研究生在忽悠导师，这对于项目来说是致命的。 其次，项目的权利与义务从一开始就很模湖，很少有人愿意为很不确定的前景而工作。这个问题在公司里很简单，我拿工资我这个东西就要弄出来，我就要通过质量保障人员的验收，在这里不是这样，项目开发的费用一般是导师后来给的，开发者对此一无所知，自然也就缺乏激情。如果导师自己参与项目的设计开发还好，研究生只是跟着干，研究生不干了，自己还可以顶，如果导师具备相当的人格魅力，愿意学习的研究生还是乐意干的，导师自己也是QA,可以审核研究生的开发成果。但大多数导师是委托式的，把所有的任务都交给你了，但是，你不清楚你可以得到多少，所以很多人只是在凭个性而工作，干自己喜欢干的事，这里也没有QA,最后的结果自然而知，即便流产了对研究生来说也没有什么可惜，因为他已经得到了锻炼。 第三，研究生大多是没有项目经验的，前面也没有积累，代码大多是在心血来潮下写出来的，没有设计，也不考虑扩展，经常后来自己都读不懂，缺乏整理东西的习惯。举个例子，项目中要用到一个复杂的Applet,这个Applet在用java写完后，还需要数字签名，同时applet的工作模式如果变了，还需要更新一些其他的东西，换句话说，如果用户需求变动导致applet的代码和工作模式变了，虽然可能只是几行代码的工作，但是开发人员必须进行重新数字签名和更新一些其他的东西（假设开发人员是个新手，他甚至都忘了上次是如何数字签名的，这次他必须重新去找资料。重复工作的痛苦对于程序员来说是不言而喻），在再次编译签名和更新相关东西后，可能许多时间就过去了。“改动怎么就这么麻烦呢？”。其实这只是一个简单的项目自动构建的问题，只要把所有重复的事情都提取出来，让计算机去干就行了，但是一个新手，往往会陷入前面痛苦的泥沼。 第四，薄弱的测试和质量保障。测试应该在项目开发中占有很重要的比例，导师与研究生的开发弱化了这个环节，这里不再深述，没有专业的测试，一年之后还会发现BUG就没什么稀奇了。再者前面提到的质量保障，缺乏平时关于软件质量的监督，所有的问题在交互之日接踵而至，项目迟迟延时就不足为奇了。 成功的导师与研究生的开发，需要解决的问题太多，除了上述的以外，计算机研究生的培养模式也是值得深思的。 |
|
|
