高级软件工程(殷秋丰) 2016秋 2015秋 2014秋 2013秋  课程号:0WR001
2016秋 2015秋 2014秋 2013秋  课程号:0WR001
10.0(1人评价)
10.0(1人评价)
  • 课程难度:中等
  • 作业多少:很多
  • 给分好坏:一般
  • 收获大小:很多
选课类别:未知 教学类型:未知
课程类别:本科计划内课程 开课单位:信息科学技术学院
课程层次:未知   学分:6.0
简介 最后更新:

 《构建之法 - 现代软件工程》已经出版。(购买; 第二版  第一版豆瓣讨论)(多看电子书版本

本课程是科大与微软亚洲研究院联合培养的课程。

排序 学期

评分 评分 1条点评

boj 2013秋
  • 课程难度:中等
  • 作业多少:很多
  • 给分好坏:一般
  • 收获大小:很多
  • 难度:中等
  • 作业:很多
  • 给分:一般
  • 收获:很多

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

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

课程分为三个部分:

  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 重要。

10 0 复制链接

殷秋丰

教师主页: 戳这里

其他老师的「高级软件工程」课

石贝贝 10.0 (1) 2023秋 2022秋...
李京, 周英华 6.0 (1) 2015春
周颢 4.7 (9) 2024春 2023春...
孟宁 2.2 (6) 2024春 2023春...
李京 3.0 (20) 2023秋 2022秋
未知 2022秋 2021秋...
白天 2023秋 2022秋...

殷秋丰老师的其他课