原文地址：http://www.cnblogs.com/xinz/archive/2011/05/16/2048044.html

现代软件工程讲义 0 课程概述

这门课的教学方案在这里. 根据学生和学校的具体情况, 可以进行调整。 

师生关系

首先要明确的是, 在这门课中的师生关系是什么样的.  大学目前的师生关系是怎样, 什么样才是理想的师生关系nbsp; 我们先看一些例子:

Retailer / customer (餐馆/食客)/strong>

一些学生说, 我既然交了学费来上学, 就像交了钱去自助餐厅一样, 想吃多少, 想吃什么, 都是我决定.  如果不喜欢, 就去下一个餐厅好了。 上课能这样么nbsp; 在饮食行业, 顾客拍拍屁股就可以离开一个餐馆.  在一些学校里, 是有不同的老师上类似的课程, 同学们可以根据老师的介绍和师兄师姐的提醒选择适合自己的老师。 但是在学校里,  学生必须要在一定时间内作出选择 (必修课), 老师掌握着最后给学生多少分, 学校掌握着毕业证。  所以不能把餐馆/食客的关系照搬过来。 学生们非但不能成为有主动权的顾客, 反而会被人以分数/学位/毕业证相要挟, 成为下一种关系中的弱者:

Boss / employee (老板 / 雇员）/strong>

在学校里, 很多学生把自己的指导老师叫做 ”老板”, 学生变成打工仔或打工妹。 不光有大老板, 还有小老板,  因为大老板太忙, 平时都是小老板在管理。 在一些学校, 博士生要延期一年才能毕业成为了众多潜规则之一. 学生虽然是”雇员”, 但是并没有雇员的权利。

Baby-sitter / babies (保姆 / 幼儿) /strong>

还有一种情况,  老师像保姆一样, 为学生操办一切, 把课程内容煮成婴儿食品, 一勺一勺地喂给同学.  同学们有什么问题, 都去找老师搞定。 学生把老师反复咀嚼过的东西再咀嚼一遍, 这种模式也许可以叫做 Learning by re-chewing.  这个模式和这门课的 “做中学” (Learning By Doing) 有很大的区别。

Buddies / Buddies (哥们 / 哥们) /strong>

还有一种情况是, 老师和学生心照不宣一起混,  “你对我好, 我就对你好”. 这里有一条新闻:

http://edu.163.com/10/1106/10/6KQ4JC8800293L7F.html  

部分大学课堂师生心照不宣一起混

“老师与学生一起应付”，这并非大学生们学习之余的调侃之语，而是不少大学课堂的真实写照。

Stranger / Stranger （路人甲 / 路人乙）/strong>

很多学校有巨大的新校区,  老师对着百人左右的课堂宣讲幻灯片, 下课后就开车回老校区或市区的家里. 老师不认识学生, 也未必有精力了解具体学生的情况.  双方形同陌路。

Prison Guard / Prisoner (狱警 / 犯人)/strong>

还有一种情况是老师想方设法让学生来上课,  点名, 突然考试, 指纹打卡, 等等.  学生则想方设法逃课。 学生视上课为坐牢, 巴不得早一点解放。对于一些同学来说,  老师就是学生和 “自由” 之间的一道障碍。  

说了这么多,  我心目中理想的师生关系是什么nbsp; 是“健身教练 / 健身学员” 的关系。

这个道理对IT 行业的学生也是一样的, 在人潮汹涌的招聘市场, 我们可以问一下那些学生 –

你平时在学校里是如何为将来的职业准备的/p>

a) 不经过准备, 直接上

b) 只学理论, 没有实战

c) 用比实际工作要求更低的水平训练

d) 用和实际工作一样的要求训练

e) 用比实际工作高一倍的要求训练

在这片神奇的土地上, 我们或许还可以听到 f) 的回答:

f) 我不用准备, 我爹叫阿刚。 

这样公平么nbsp; 很多人会问。  如果一个同学写了没有任何bug 的程序, 得到10分, 另外的同学程序有 1 个bug, 得到9.5 分, 程序编译都不过的同学, 也得6分, 那你觉得这样对写了全对程序的同学公平么nbsp; 如果一个同学的程序连普通的冒泡排序都比不过, 老师和TA在花时间陪他玩,  他欠我们分数, 这样的人不得负分得什么/p>

做中学

上《现代软件工程》 的同学, 都是大三到研一的同学,  应该具备基本的学习能力和开发能力,  软件工程和其他类的工程 (如航天工程, 化学工程) 不一样, 我们每天都可以用到软件工程的产物 (软件),  搭建, 学习一个软件开发平台比航天化工要容易很多 (注: 在自家后院放二踢脚不是航天工程), 相关的学习资料也是非常容易获得。 在这个情况下,  学生们可以在“做”的过程中学习, 这也叫”做中学”.  做了, 有疑问, 再问老师, 问专家, 这样学习的效果会好很多。 我为这门课准备了三本课本, 一本指定的阅读教材, 二十本参考书 (对, 20 本), 同学们平时可以多看书。

真实的项目

在这门课中, 我鼓励学生做自己决定的项目, 但是要求他们要做”真实的项目” – 有真正用户的软件。  那些 “经典” 的项目, 例如图书馆管理系统, 学生学籍管理系统等, 是不符合我的要求的。  项目要有活的用户, 只有活的用户才有活的需求, 才有活的场景, 活的测试用例。 只有活的用户才决定同学们写的软件是否值得使用, 有些团队写的小软件很好用,  在合适的用户群中引起共鸣, 短短时间内, 就会有几千到几万个用户 (像北航团队开发的魔方程序), 也有的团队费了老鼻子劲, 写出来的东西用户量小于10, 自己团队成员包括在内。 这些不同的用户数量会迫使项目团队反思当初在需求分析, 设计上的问题。 另外这门课并不是算法竞赛, 或者代码集中营, 大家比的不是如何快速敲打出某个算法, 而是如何在有限的时间内交付有价值的软件给特定的用户。 “真实”这一条件也促使大家做 “现实”的项目和项目管理。 很多学生有宏大的梦想,  但是在短短的 8 周团队项目时间内, 甚至短短的 16 周课程时间内, 他们发现宏大的构想被自己程序的bug 搞得千疮百孔， 轰然倒地。 

学生的收获

在这门课里, 有付出, 就会有收获, 收获体现在下列方面:

1. 写出一个可用的, 有实际用户的软件。 这对大多数人来说, 是第一次。
2. 完整体验软件生命周期, 对于生命周期的各个阶段有实际的了解。对于软件设计有实际的掌握。 对敏捷软件开发的具体技术有实践能力。
3. 了解软件团队的各个角色, 和各个角色的互动.  对于其中一个角色有实际的深入体验。
4. 学习如何与不同的角色打交道, 培养团队精神, 学会解决冲突的几种方法

这个课程不讲什么nbsp; 这个课程不具体讲某一个程序设计语言, 也不讲 UML, 设计模式。 这些内容都应该属于其它课程。

但是从课后的自我反馈来看, 学生往往在某一门“程序设计语言”很有收获, 为什么呢nbsp; 第一是因为这门课的个人项目和结对项目让他们有充分的机会学习和巩固关于某一语言的知识;  另外, 他们第一次把某一门语言用到了一个有分量的实际项目中去, 从而深入地了解这个语言的特性。这可以说是<现代软件工程> 的一个好的副作用。

任何一门课都不会一帆风顺地讲下来, 所有人皆大欢喜。 老师学生需要时间来适应，交流,  才能逐步提高。 吹了这么多, 到底学生反映如何下面是清华大学的学生对这门课的不记名评价。

上好课很难, 老师, 学生都不容易, 这个博客讲了一些。

一些学生清澈的， 充满求知欲的眼神告诉我, 他们最关心的是 –

                怎么用最小的代价, 让我过了这门课!

上了这门课就知道代价了。