现代软件工程系列学生和老师都不容易

老师的难处 - V2.0 的困难

有笑话说某人请客, 客人无论是坐轿或是步行前来, 主人都能奉承一番。有客人说自己是爬着来的，主人奉承说 - 稳妥之至!

据说有些学校的有些课还是沿用 N 年前的教案和教材, 这当然稳妥之至。我看到学校用很多年前的稳妥教材把学生送走之后, 会说 - 我校一贯鼓励创新, 培养了大批创新型人才...

这些创新型的同学, 都到这里碰面了:

招聘会

我讲的课是 <现代软件工程>, 我还是希望与时俱进的。当然, 要变化, 就有风险。业界常说某软件公司的产品要到V3.0 才好用。从我的经验来说，在V3.0 之前的V2.0 是比较困难的一个版本。 V1.0 初试啼声，市场反映不错，评论家也主要评点产品的创新点及潜在影响，对缺陷往往比较包容。 V2.0 一方面要继续原有的突破，把V1.0 来不及实现的功能都搞出去；同时，V1.0 的发布产生了更多的机会，很多人有了新的想法；另一方面要调整内部结构，让产品更稳定。这几种不相容的思路混在一起，加上用户和评论家更高的期望值，V2.0 很可能是不如人意的产品。

在2009 年初, 我在清华大学软件科学试验班的《现代软件工程》也讲了两年 (2007, 2008)，算是V2.0，从结果上看，也碰到了类似的情况，下面是一个列表比较两届学生的匿名反馈:

评分内容	2007	2008
热情、认真、投入、严谨，教书育人	95.45^±3.80	95.00^±3.42
讲课思路清晰，重点、难点突出	94.55^±4.04	89.29^±5.77
讲解生动、有吸引力，能激发学生的求知欲	92.73^±5.15	90.71^±5.37
师生互动，鼓励学生质疑，并给予思路的引导	94.55^±4.04	93.57^±3.69
提供或推荐的教学资料有助于学生学习	93.64^±4.23	86.43^±8.19
作业等课程训练有利于课程内容的学习	94.55^±4.04	90.00^±4.95
考核及评价方式能激励学生主动学习与钻研	92.73^±5.15	87.86^±4.88
注重学生创新意识和独立思考能力的培养	92.73^±4.37	91.43^±4.44
对学生课外学习给予指导、建议	92.73^±4.37	91.43^±4.92
学习本门课程后有收获	92.73^±4.37	90.00^±5.38

可以看到，在10个栏目中有4个项目的反馈有明显下降。

-讲课思路清晰，重点、难点突出：下降了5个百分点。我在2008 秋季开学前还把整个课件都重新整理了一遍，增加了不少内容，相比2007年我第一次在大学讲课，应该只好不差吧? 为什么同学们会有这样的反映? 是新增的内容没有很好的准备，还是增加得太多了，让人觉得眼花缭乱，不利于吸收?

-提供或推荐的教学资料有助于学生学习: 除了教材是提供了新版本外(移山之道的第二版)，我在2008年提供了更多的参考资料，最大的手笔是给每个小组一本 <梦断代码> (btw, 学校不让报销), 让他们读后写读后感。后来几篇读后感都挺好的（link 1, 2, 3, 4, 5）。这一项的评分的标准方差(+/- 8.19) 也明显大于其它评分，说明不同学生的反映差别很大。

-作业等课程训练有利于课程内容的学习: 这门课的结对编程 (Pair Programming)作业和去年不一样，是在一个共同的编程接口(API) 上分为 DEV 和 Test, 分别写实现和测试. 主要练习

design by contract,

test case development,

stress test,

optimization, 等。

但是在执行中不是所有学生都理解问题和要求，要在看不见功能实现的情况下写test case, 我想对绝大部分学生都是头一次。我应该讲得更详细一些。而不是让所有同学自己摸索。我期望同学们课后有问题就问负责API 的同学，都是同一个班级的，不是很简单的事么? 但是很多同学都等到下一周上课的才说，理解不了… 然后又产生关于 "你是否花了时间看了我写的API" 的争论… 后来又产生"写Test 比Dev 简单，不公平" 等等意见，导致多用了一周时间完成整个作业。相比之下，2007年的作业是“两人组对写一个简单游戏”, 这很有趣，也不难，因为自己可以决定功能的多少，但是一个游戏是否比2008年的作业更“有利于课程内容的学习”，这就不好说了。

- 考核及评价方式能激励学生主动学习与钻研: 哈哈，2008年的课程在评价方式上的确有改变，而且这也是出于“激励学生主动学习与钻研”的目的。这在课程中也引起了学生的激烈讨论, 具体讨论可以看一些小组的blog 及评论。我觉得这事实上是挺好的现象，软件工程的一些道理，就是要辩论才能体会；一些我们同学们经常抱怨的事情 (e.g. 这肯定是某公司的bug)，似乎我们也没做好, 我们经常嘲笑别人软件发布一拖再拖，但我们学生们的软件发布也推迟了。在最后的评审上，我请了上一届的学生，别的学校的老师，以前信息奥赛金牌获得者，程序员，杂志员杂志的编辑，《梦断代码》的译者（不过他没出现）。我觉得这个考核及评价方式挺好的，但是看来同学们的总体反映并不好，是继续“深化改革”呢，还是让大家都好过一点，洗洗睡算了?

令人高兴的是，两届同学都同意我还算"热情、认真、投入、严谨，教书育人", 说明我本质不坏，如果别的条目的评分都上升，唯独这个条目下降了，我可能不好意思把评价公之于众。不管怎么说，还得好好改进教学，别对不起学生的评价。

同学们也不容易

这是一个清华同学的反馈:

我的若干看法 -- 课程刚技术时提交过一个“看法”，但是现在过去一段时间了，感觉有点不同了

1.我对课本有点抵触，尤其是《移山之道》。主要是觉得“废话”太多了，里面聊天和诗歌有点过多了。书本身其实还不错，但是上课时作为课本看感感觉信息量太低了。实际等课程结束后我把它作为课外读物又从头看了一多半，其实还不错，只是它有点像连续剧，不从头看或者不连续看就被人物关系搞的晕头转向了。不过您大可坚持您自己风格，大多数目标读者觉得好就行了。

2.物质奖励还是挺不错的，即使是一支纪念圆珠笔或者帽子或者粘贴，都很有趣。但是别给钱。

3.制度总是和人过不去，人总是和制度过不去，所以怎么弄总会有人不满意。关于考核方式等等其实只要公平合理就行。

4.当TFS管理员其实挺有趣的，但是最后发现90%的工作是安装服务器（不知道这一天TFS装了多少次）

5.VSTS感觉一直是当svn用的，上课时讲的高级功能没用上。像item之类我自己感觉还不如用笔纸或者email。 item这种大工程才用的放在小工程里实在很别扭 -- 尽管我知道是为了学习而这么做的。

6.我不建议您为了避免辩论而改革，俗话说“抬杠长学问”，只要不伤了和气其实挺好的。

7.我觉得像这种开发方法之类的东西就像设计模式，非常抽象，本来就不应该归结成概念死记硬背，但是为了继承和发展又不得不这样做。上完这个课以后我第一反应其实是“什么都没学到”，但是这个其实说明您讲的还是不错的，不死板。

8.不管怎样，软工是我上过的最有趣的课之一，感谢邹老师。

我问了一些刚刚毕业的软件专业的同学，软件教育迫切要改变的做法是什么? 下面是一些回答：

a) 实践! 软件教育离不开实践，不要太强调闭卷考试，老师一定要让学生实践，实习。给一个真实的客户做项目和自己幻想一个需求来做项目是有很大区别的。自己从头写程序和维护别人写的代码是有很大区别的。没有真实的需求，没有软件的增量开发，没有团队合作，程序设计和软件工程中的大部分理论都沦为空谈。

b) 讲为什么! 学生上了很多课，反而觉得很迷茫，这些课的意义是什么? 为什么有这么多的原理，数据结构，模式和算法? 不知道我学的东西有什么用，怎么用。老师似乎不想告诉我们这些课程在实践中的意义 (或者他们也没实践过? )。学生只有死记硬背来应付考试，考试后全忘记。

c) 打好基础，其他自学! 好好学基础课，特别是算法, 数据结构, 编译原理，操作系统。其他课的内容用到了自己学就可以了。

d) 不光是代码! 软件教育不是孤立体，希望在软件教育中把文科的知识联系进来，和设计联系起来; 把软件/IT 行业有趣的发展历史放进来 (讲讲图灵，冯诺依曼，讲讲Smalltalk, 各种语言的源和流)。培养学生对这个行业的兴趣、热情和敏感。提倡互动，介绍同学上相关的论坛，网站，开拓视野。