前段时间，教研室正在做一个小项目，准备作为一个作品参赛。可是在提交作品的前一天，大家进行最后的模块整合时，发现一个重大bug，把之前的项目计划打破了，作品不得不推迟提交。这让我不禁想起了我们之前做的另一个项目，有次要想外地的客户进行阶段性演示，在前一天晚上整合项目各模块时，发现了重大bug。一开始大家怎么也找不到引起bug的原因，结果一起奋战至第二天凌晨3点，才初步解决了问题，然后大家各自回去睡了一会儿，接着乘早上5点的火车出差见客户。
为什么我们总是在项目要提交或者进行阶段性验收时，发现重大问题，而不是在平时开发项目的时候？我想，一个原因是我们在项目开发时，几乎就没有应用软件工程方面的思想与方法。目前，作为计算机专业的研究生，我们平时软件开发方法还属于“作坊式”的，我们教研室是这样的，我想我们学校其他教研室的状况也会跟我们类似，这是十分可悲的。有时我们的研究课题会更偏向理论，这时也许不需要软件工程；但是当真正接到一些项目，需要多人协同开发时，没有软件工程将会大大提高项目的风险。
我们在大学里接到的项目，一般不会很庞大，绝大部分是中小规模。即便规模不大，但在开发过程中，没有代码版本控制，没有软件测试（除了手工的模拟测试），应该不能算是规范的软件开发的。很不幸，我们的团队目前就是这种状态。接到项目，分一下模块，大家各自按分的模块进行编码，代码根据时间保存成一个个压缩包，项目需要整合时，就将大家的代码复制到一台电脑上，合成一个项目，然后手工运行一下，作为测试。这就是我们团队目前的“作坊式”开发方法。
知道“作坊式”的开发方法不好，那为什么不早点改变呢？那是因为改变是要有代价的，要摒弃原先的开发模式，学习新的开发方法，更重要的是改变我们平时做事情的思维模式。这些改变的代价不小，但我觉得是值得的。尤其是每当项目出现bug，但原因并不是代码本身，而是由于我们协同开发时的沟通出了问题，每当我们被项目搞得焦头烂额，感觉像是《人月神话》封面那些陷入焦油坑的困兽时，我就愈发迫切想要改变。
不过，一下子就改变我们目前的开发方法也是不实际的，得一步一步来。目前打算让我们教研室的同学每隔1～2周进行一次技术交流，大家交流一下有关软件开发方面的心得。另外，还想弄一台电脑，专门用作我们平时做项目的服务器，让大家可以实践起来。
想法很好，就看我们能不能坚持下去了。
