软件工程总结

时光荏苒，岁月如梭。转眼间，这一个学期就这样过去了。。

先说点和软工不相关的事情

这学期是我有史以来最忙碌的一个学期。

编译大作业：高级C0编译器，包括所有要求的优化。共计约5000行代码；

软工大作业：队内第三代码量（5000余行）、第一博客量（33篇）、第一宣传量（2个）、第一文档量（3个）；

数据库大作业：一人完成，6实体，已申优，约2000行代码（包括UI）；

Win8开发大赛：BubbleBreaker；

实验室1的活：根据论文写Cobra，1000余行；

实验室2的活：写一个Arduino小程序：200余行；

两门课考试；

……

我决定寒假好好修养生息。

然后再说软件工程

首先，这学期的软件工程课还是非常好的。以前，我都是作为一个纯粹的Dev，写写代码，顶多再写写ppt，写写doc，答一答辩。

通过这个软件工程课，通过作为一个真正项目的PM，我学到了很多东西。

这分为两个：技术上的和人事上的。

技术上：

1. 架构师非常重要。一个好的架构不只是像程序设计书上那样的几个设计模式的堆叠，也不只是面向对象课程中的那堆UML图。真正好的架构是，Dev无需知道他分外的任何事情，就可以根据API和文档写出高质量的代码；美工们无需知道代码是什么样的，就可以画出需要的素材。

我和黄杨两个PM，黄杨更倾向于Product Marketing，我更倾向于Project Manager。他C++能力比较强，有过几个小游戏经验，相反我虽然项目经验比较多，但C++实在是不熟。共同点是，我们都没有架构设计的经验。于是，我们的架构一开始就设计挫了。后来，他对其进行了修改，才形成了最终的版本。对于架构，只能说我们太嫩了。通过这次真正的游戏设计体验，我们对于游戏的架构设计有了一个很深刻的理解。

2. 关于习而学

项目的M2和M3阶段再一次证明了习而学的失败。我们都属于习而学，之前不懂cocos2d，一边练习，一边学习。结果呢？写的代码跟shit一样。

事实多次证明习而学比学而习要浪费时间。正确的顺序是，先学习相关技术和他人的经验，然后再进行练习。

3. 关于对项目的预估和控制

项目大小难以预估，这是众所周知的。但是，我们有义务尽可能的预估准确。

我们在一开始认为这个游戏可以简单也可以复杂，时间比较灵活，一个学期绰绰有余。当时甚至还觉得可以把它移植到win8中参加win8开发大赛。没想到cocos2d-x是一个如此神奇的东西，C++是一个更加神奇的东西。项目的代码量在日夜之间，从一开始预估的5000行到8000行到20000行。如果说，我们在一开始就能预估准确的话，我们就会在m1阶段就要计划加紧项目的进展。

在项目的最后阶段，邹老师催的很紧，希望我们尽快发布。我们也做了很多个艰难的决定。这一切都是源于我们对项目的控制出现了问题。我们错误的预估了游戏主体所占的比例，其实，游戏周边的一些内容，比如菜单、美工、游戏体验，更加费时费力。

项目大小的预估和控制是需要经验的。通过这次软工大作业，我对项目大小的预估有了更加深刻的理解。

4. 关于C++

C++真是一门十分蹩脚的语言。我在上个暑假学习了scala，这个学期又学了一点lisp，再加上本来就会的C#和java，这类高级一些的语言真的比C++要好用好多。

其实之所以我们需要C++，是因为我们既需要高级一点的面向对象等技术，也需要低级的指针、手动内存分配和回收等等，还需要开放，以应对多个平台多种架构。这让我们不得不使用C++，因为它貌似是支持这些全部特点的唯一语言。

但是，是不是到了改变的时候了？

人事上：

在这个项目中，技术其实我管的不多（有黄杨大神罩着），我管的更多的是人事上的事情。

1. 分配任务

我在一开始的第一个任务就是分配任务。我选择了两个人当做PM，事实证明这是相当正确的。如果只有一个人当PM，那他一定会累死。

我认为我还是比较民主的，首先先照顾组员的兴趣，不想当dev的就不让他当dev，想当美工的就让他当美工，想不干活的就让他当test。

2. 奖惩措施

我认为设立一个明确的奖惩措施是十分有必要的。我们组就没有一个十分好的奖惩措施。比如说M1之后的项目组员评分，我为了不得罪人，给组员的分数是一个以1为公差的等差数列（排名是反映真实情况的），而且对MagicCode组的评分（组员分数差别较大）嗤之以鼻。

但是现在想来，评分就应该差别大一些。因为：

(a) 评分应该反映真实情况；

(b) 评分应该可以激励好好工作的人，惩罚不好好工作的人；

(c) PM就是个得罪人的人。不得罪人的PM不是个好PM。

于是，M2的评分我给的差距就比较分明。事实也确实是这样。

3. 关于PM的性格

我直到M3才变得严厉了许多，可是太晚了。这次软工大作业给我的一大教训就是，不要心太软。

心软的后果就是：

Dev:这个怎么做？

PM:blablabla....（解释了n分钟）

Dev:（写了一行代码之后）然后怎么做？

PM:blablabla...

Dev:（又写了一行代码）然后怎么做？

PM:...

或者是：

Dev：这个我不会做，我不做了。

PM：（一不小心）唉你太笨了，我帮你写吧，回来请我吃饭（然后回去默默的熬夜。。）

4. 关于Daily Scrum

Daily Scrum的作用我直到期末才明白——反馈，然后更好的做后面的事情。

反馈的频率决定应对变化的反应速度，比如说，一个PM或者Dev改变了框架中的某个内容，当天，其他人就应该知道了这个消息。这也是Daily Scrum和Weekly Scrum的根本区别。

但是，我们当时没有想到这些，我们的Daily Scrum，说白了就是个应付而已。这也决定了我们组对于变化的反应速度慢，甚至会出现A改了某个API，B等一个星期后才知道这个消息，于是这一个星期的活又得重新来过。

总结

总而言之，也许在这次大作业中，我不是一个称职的PM，但是通过这次PM经历，我真的学到了很多。不仅有技术上的，更有人事上的。人比代码复杂多了，学好编程非常容易，管理则需要大量的经验。

接下来，享受假期吧。