课程快要结束了，回想起整个课程来，和最初的设想差别的确很大，我也没有想到我们这组的进展会如此的不顺利。用一句话来说，“很受伤”。我前段时间和一个J40的师兄（Mr. 8）聊天，他说他最近在看一本软件工程的书，书中提到了一个“人件”的概念，和“硬件”“软件”并列。他很黯然的对我说，软件工程其实就是“人”的问题，当时我就有“相见恨晚”的感觉，因为我当时也很黯然。还是一点一点来说吧。

      首先，这门课程的确讲授了软件工程方面很多很实际的知识，同时课程也设计的循序渐进，一个学期下来，虽然失败了，但是我收获很多。以前不知道软件为何物，单纯的认为软件是代码堆起来的金字塔，现在看来软件工程中方法要比写代码重要，一个有效的方法可以有效的减少废代码的数量。

      但是这么课最大的问题并不在于知识的讲授，而使如何在软件开发过程中处理人与人之间的关系。在现实的软件设计过程中，大家都约束在一定的权利和利益的关系之中，所以各个角色能够各司其职，各尽其能。但是在我们的课堂上，我们都是平等的，所以大家只是被约束在一个一文不值的“道义”之中，一旦涉及自己的根本利益，比如“玩的时间”，“排练的时间”，“陪女朋友的时间”，那么让“道义”见鬼去吧。有人提出让PM掌握一定的给分权利来约束大家，实际上没有从本质上解决这个问题，毕竟PM的地位和组员是一样的，甚至是至交关系，谁也不愿意看到自己的同学因为自己而挂了（虽然这是由于他没干活造成的），所以这个约束作用也是会大打折扣的。如何在软件工程这门课上模拟出类似真实软件开发的环境，还是需要“大智慧”的人去发现。

      实际上周老师说一开始我们组是最安全的，着实把我吓了一跳，说的我都有点相信了。但是如果是我们班的同学应该知道我们组的成员是一种什么样的情况，某些人自己心里也是明白的。所以即使是设计过程说的多么天花烂醉，一旦到实现的时候总会出现很多掉链子的情况，因为在设计过程中他根本没有去考虑自己的利益，但是一旦实现了，那么他就开始后悔了，推三拖四的。其实我们组是最好的例证，虽然我们的计划是11月定的，但是我们组的代码大部分都是12月中旬写的，更不用说连调了，这其中就是因为有些人没有干活。还好，这些人不是很冥顽不化，在我的“悉心劝说”之下还是动手了，以至于我们的工作得以完成。

     其次，我们组，应该说是我对软件的需求认识不够，在软件设计的过程中提到了自以为合理的需求，实现的时候却发现无比的艰难，后来我们的组员根据前面的设计进行了改进和简化，才使得我们的项目得以顺利进展下去。在很多软件工程的书中都提到过这种现象，不知道是不是叫做“软件黑洞”，如果对软件需求定义的不合理，会毁掉一个软件，但谁才能知道“合理”的真正含义？

    剩下的一些问题则是能力问题，比如语言不通，不懂C#，不懂Wpf，不懂Boost，不懂MySql，好像我们几乎没有使用什么以前会的东西来编程，不过现在这些应该都算弄明白了，也是一个不小的收获。又比如方法不通，很多人都没有学过设计模式，软件的可扩展性极差，可维护性野很差，给我的映像是，“我们始终在改代码”。

    最后说一下这门课程的评分，其实作为一个大四的人，已经么有什么追求了，所以只要能够给我通过的话，我不是很在意我得了多少分。但是这么课程的给分还是有点不合理。首先PProject就像一个笑话，前前后后折腾了半个学期，还没有什么很好的结果（很多DEv都倒在了Test的手中），评测过程也极其的不透明（自己的程序怎么挂的不知道，Test甚至不通知一声），评测标准也很不合理（不知道是Test的方法错了还是Dev设计有问题，同时分别Test给分和Dev的给分本来就不公平）。其次是T Project用工业界的你死我活的方法（在P Project中也用了）来给我们评分，也就是说即使有时你很努力，但是你还是什么都得不到。但这只是一门课程，这样做使得这么课的性质就变了。

好吧，就写这么多吧~~

有谁想拍就拍吧~~~~

------ by  Hu Wei