这门与微软亚洲研究院联合开设的课负担很重，但的确能学到很多知识。

这门课用的是《编程之美》作者邹欣老师的软件工程讲义，后来结集出版在了《构建之法》里。这个书比学校的软件工程教材实在好太多了！读起来一点也不觉得无聊！

课程分为三个部分：

1. 个人项目：词频统计
2. 结对项目：电梯调度算法
3. 团队项目：敏捷开发产品

个人项目

项目的 spec 很简单：一个目录里有若干个文本文件（可能有子目录），要统计这些文件中每个单词出现的数目，按照出现次数降序排列。

初看起来，除了递归查找所有文件的 API 需要临时查一下以外，这不就是一个算法题吗？老师让我们做这个项目，就是要让我们认识到软件工程项目与算法题的区别。

性能方面：

1. 现在的计算机是多核的，要利用多线程，把不同的文件分配给不同的线程处理，最后再合并。
2. 不能主观臆测代码的性能瓶颈，而要利用 profiler（这个其实是给 Visual Studio 的强大 profiling 功能打广告的）

代码风格方面：

1. 变量名、函数名必须有意义。

鲁棒性方面：

1. 目录里有一个无权访问的文件，是否会导致程序崩溃？
2. 文件里的不可见字符应当被跳过。

结对项目

这个也是算法题，不过没有最优解的。我觉得主要锻炼三个能力：

1. 结对编程
2. 在给定的框架里编程
3. 没有最优解情况下的逐步优化

spec：一座 20 层的大楼里有 4 部电梯，其中两部电梯比较大（重量限制大），另外两部电梯比较小。电梯在相邻两层之间移动的时间总是 5 个时间单位，开关门的时间也总是 5 个时间单位。大楼里有 1000 名员工，需要用电梯的时候就会按向上或者向下按钮。每部电梯能够知道当前位置、轿厢里的当前重量。开门的一瞬间，电梯可以决定是否切换运行方向；电梯关门的一瞬间可以修改目标楼层（必须是同方向）；电梯到达目标楼层就会开门。

每个乘客的平均体重和分布已知。当电梯开门时，首先下客，然后跟电梯相同方向的乘客就会按照先到先得的顺序进入电梯，直到电梯达到重量限制为止。

需要设计一种电梯调度算法，优化在上下班高峰时乘客的平均等待时间：

1. 上班高峰，90% 的乘客从 1、2 楼随机进入，到达 3~20 楼。10% 的乘客在各楼层间随机运动。
2. 下班高峰，90% 的乘客从 3~20 楼随机进入，下到 1 或 2 楼。10% 的乘客在各楼层间随机运动。

为了避免把这么好的思考题破坏掉，我就不贴我们组的算法了。

当时为了查看不同调度算法的效果，我专门用 cygwin + C + ncurses 做了一个可视化工具，来动画显示电梯的位置、电梯目标楼层、电梯内人数、各楼层的等待人数、平均等待时间等信息。一开始我们拍脑袋想的算法用可视化工具一看，干了好多傻事。这让我们引入更多的考虑因素和特殊情况判定，不断优化算法。

附上当时我设计的电梯调度算法：AlgorithmDesign.docx

当时提交的代码：elevator.zip

团队项目

团队项目是这门课的重头戏。学校软件工程课一般是让学生写教务系统、报修系统之类无聊又没用的东西，而且搞一大堆设计文档、UML 类图、流程图之类形式化的设计方法。但 MSRA 高级软件工程课程的团队项目是做一个产品并实际发布，采用的也是互联网公司常用的敏捷开发方法。

首先是自由结组，每个团队不超过五个人，大家纷纷开始抱大腿。（事实证明，大腿有时候也靠不住。开发软件的时候，稳定的输出胜过不确定的爆发）团队按照 PM、Dev、Test 来分工，一般是一个 PM，一个 test，剩下的是 Dev。

设计阶段每个人都要写博客来阐述自己的产品构想、用户故事、竞品分析，然后团队选择一个产品写出 NABC（Need、Approach、Benefit、Competitiors），具体开始做。

开发过程重度依赖与 Visual Studio 集成的 TFS (Team Foundation Server)。TFS 除了有类似 SVN 的版本控制功能，还有项目管理功能。开发过程首先被分为两个 milestone（beta、release），每个 milestone 被分为若干个 user story，每个 user story 又细分为若干功能点，每个 milestone、user story、功能点都分配给负责人。

在 TFS 里可以看到项目进度的燃尽图（burn-down graph）和每个人提交代码、新建任务、完成任务的趋势图，只要是不想被鄙视的成员都不会轻易懈怠。

按照规定，我们每周是要开不超过 15 分钟的每日立会，就是在一天的工作开始之前，向团队简要汇报进展和遇到的问题。我们组由于我早上起不来床，以及大家有组会等原因，每日立会是没开成。每周还要开一次大会，汇报一周的进展和分配下一阶段的开发任务。有时候我连大会也翘了，气得 PM 不得了……

开发阶段，每个团队的 PM 每天都要写博客总结当天的进展（daily scrum），但事实上由于大家大多是三天打鱼两天晒网，PM 也往往没得可总结。各组的博客如下：

• 三缺一：Academic Reader，搜索阅读二合一的论文助手（Windows App）
• P. O. S.：新版瀚海星云网页前端
• Cool-Yogurt：微博可视化数据分析，以朋友的视角浏览微博
• CodeBreaking：soip.net，模仿 DomainTools 的域名搜索工具，这个就是我们组啦

可以说这四个项目的 idea 都不错，但大概是由于我们没有开发经验，花了很多时间，大多数组交付的产品却没有达到可发布的标准。主要的原因可能是

1. 过分依赖“明星程序员”，明星的懈怠阻塞了整个团队；
2. P. O. S 组和我们组做的都是 Web 项目，而大家大多没有 Web 开发经验，对计算机网络也不了解，背景知识的缺乏降低了软件开发的效率，挫折感也降低了大家的积极性；
3. 功能上做了太多加法，开发进行到一半又添加临时想出来的功能，导致软件不能按期完成；
4. 没有按照 Daily scrum 的要求，保持快速迭代和反馈，一些技术难题藏着掖着直到快到 deadline 才发现。

如果大家有机会去 MSRA 联合培养，高级软件工程课一定不要错过！真该让学校的软件工程老师们去听听课（或者看看《构建之法》），看看敏捷开发到底是什么样，到底是 code 重要还是 document 重要。