《現代軟體工程》：師生的關係是怎樣的？

原文地址：http://www.cnblogs.com/xinz/archive/2011/05/16/2048044.html作者：鄒欣（微軟亞洲研究院首席研發經理，《編程之美》作者）現代軟體工程講義 0 課程概述

這門課的教學方案在這裡. 根據學生和學校的具體情況, 可以進行調整。 

師生關係

首先要明確的是, 在這門課中的師生關係是什麼樣的.  大學目前的師生關係是怎樣, 什麼樣才是理想的師生關係?  我們先看一些例子:

Retailer / customer (餐館/食客)?

一些學生說, 我既然交了學費來上學, 就像交了錢去自助餐廳一樣, 想吃多少, 想吃什麼, 都是我決定.  如果不喜歡, 就去下一個餐廳好了。 上課能這樣麼?  在飲食行業, 顧客拍拍屁股就可以離開一個餐館.  在一些學校裡, 是有不同的老師上類似的課程, 同學們可以根據老師的介紹和師兄師姐的提醒選擇適合自己的老師。 但是在學校裡,  學生必須要在一定時間內作出選擇 (必修課), 老師掌握著最後給學生多少分, 學校掌握著畢業證。  所以不能把餐館/食客的關係照搬過來。 學生們非但不能成為有主動權的顧客, 反而會被人以分數/學位/畢業證相要挾, 成為下一種關係中的弱者:

Boss / employee (老闆 / 僱員）?

在學校裡, 很多學生把自己的指導老師叫做 ”老闆”, 學生變成打工仔或打工妹。 不光有大老闆, 還有小老闆,  因為大老闆太忙, 平時都是小老闆在管理。 在一些學校, 博士生要延期一年才能畢業成為了眾多潛規則之一. 學生雖然是"僱員", 但是並沒有僱員的權利。

Baby-sitter / babies (保姆 / 幼兒) ?

還有一種情況,  老師像保姆一樣, 為學生操辦一切, 把課程內容煮成嬰兒食品, 一勺一勺地餵給同學.  同學們有什麼問題, 都去找老師搞定。 學生把老師反覆咀嚼過的東西再咀嚼一遍, 這種模式也許可以叫做 Learning by re-chewing.  這個模式和這門課的 “做中學” (Learning By Doing) 有很大的區別。

Buddies / Buddies (哥們 / 哥們) ?

還有一種情況是, 老師和學生心照不宣一起混,  “你對我好, 我就對你好". 這裡有一條新聞:

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

部分大學課堂師生心照不宣一起混

“老師與學生一起應付”，這並非大學生們學習之餘的調侃之語，而是不少大學課堂的真實寫照。

Stranger / Stranger （路人甲 / 路人乙）?

很多學校有巨大的新校區,  老師對著百人左右的課堂宣講投影片, 下課後就開車回老校區或市區的家裡. 老師不認識學生, 也未必有精力瞭解具體學生的情況.  雙方形同陌路。

Prison Guard / Prisoner (獄警 / 犯人)?

還有一種情況是老師想方設法讓學生來上課,  點名, 突然考試, 指紋打卡, 等等.  學生則想方設法逃課。 學生視上課為坐牢, 巴不得早一點解放。對於一些同學來說,  老師就是學生和 “自由” 之間的一道障礙。  

說了這麼多,  我心目中理想的師生關係是什麼?  是“健身教練 / 健身學員” 的關係。

大家可以從各種各樣的健身館中看到這樣的關係,  像健身，減肥，瑜珈等等。 在這種關係中, 是誰想提高自己水平?  是那些學員, 這些學員的想法得足夠強烈, 他/她才會花錢去參加這樣的健身活動。 在健身活動中, 誰要做各種運動, 流汗呢?  是學員。 誰在這個活動中對別人指指點點, 鼓勵別人更加努力? 是教練。

那為什麼教練可以這樣做?  因為教練有下面的資源:

1. 教練的資質, 教練本身應該在所教的項目中是很有經驗的身體力行者。 如果我光看了很多瑜珈的書籍和錄影, 或者得到某老師的PPT (如果瑜珈老師用PPT 的話)， 我然後就照本宣科去教瑜珈, 雖然我講的話和一個資深瑜珈教練的話沒什麼區別 – “現在開始練習冥想， 要盡量讓自己內心安靜下來，要保持呼吸均勻, 把精神集中在體內 …” 可以肯定留在我這個班裡的學生不會很多。
2. 教練有一套訓練計劃和各種練習方法， 教練(場館) 有儀器, 工具, 裝置,  不是每一個人都打算在家裡放一套各種重量的啞鈴和杠鈴。
3. 教練可以隨時指出學員鍛煉的進步和不足。
4. 教練(場館) 能召集到有一群相似基礎的隊友, 這在有些類型的鍛煉是很重要的。

教練和學員的關係如果確定,  就很好辦了。 每一個來學習的學生,  都是想學好軟體工程這門技術才來的。  各人的先天條件不同, 目標也未必相同。  有些同學想成為世界一流的程式員,  那老師就會以世界一流的標準來要求學生。

誰要在這門課中寫代碼, 做實驗, 找需求, 修bug?

是學生, 不是老師。

誰要看各種與軟體工程相關的書籍, 部落格, 並定期彙報? 

是學生。 

誰給各個學生設計練習, 回答疑問? 

老師。

如果學生的努力低於他自己目標的要求,  誰會批評這個學生? 

老師會。

有些學生說 - 老師, 你講的特別好, 我特別想提高, 但是我太忙了, 所以沒時間寫程式, 我就是來聽聽。。。

這種情況放在健身學員的類比中會是這樣:

    教練, 你講的特別好, 我特別想減肥健美,  但我太忙了, 沒時間練, 所以我辦了卡, 就是來聽聽。。。

[這種學員還真的有,  據說健身場館的很大一部分利潤是來自於那些辦了年卡但是很少來的人]

教學方法

那麼軟體工程課一般是怎麼教的呢?  我在這一篇文章裡也提到:

軟體學院的小慧老師對阿超抱怨，軟體工程這門課看似容易，實際太難教。

小慧說：我是按照經典的瀑布模型來講課的，本來以為會是高屋建瓴，一瀉千裡，但是實際情況是這樣的:

1. 需求分析：學生們都不懂企業的需求是什麼，上課睡覺。
2. 設計階段：學生們畫了許多 UML 圖，用設計工具畫了不少矩形框，菱形框，如此而已
3. 實現階段：學生們開始討論非常細節的問題，UML 圖早已經扔到一邊。
4. 穩定階段：學生們中十分之一的人開始寫代碼，其他人不知道在幹什麼．代碼大部分情況下都不能工作，所有設計好的種種黑箱和白箱測試都無從開始。
5. 發布階段：這個只有一天時間，就是最後檢查的那一天，同時還有人在偵錯工具．
6. 維護階段：課程結束了，同學們對自己的產品沒有任何維護，放假了！

最後大部分同學們都說這門課特別沒用，自己根本沒學到什麼本事，然後下個學期，新的一批學生進來重複這一過程。。。

我在文章中建議, 軟體工程的教學應該考慮讓學生一直能保持有具體的事情做, 而且做了之後能看到效果。  不要在學生剛上課的時候就要求寫一個需求分析, 學生上哪裡分析去?  如何看到效果?  

所以在《現代軟體工程》 這門課中, 我安排了個人項目, 兩個結對項目, 讓大家充分有時間把個人技術和一對一的合作技術做好, 然後再開始Team 專案。 一個理想的流程應該是這樣:

1. 開始維護以前同學開發出來的程式，理解程式。
2. 找bug，改bug，重構小部分代碼，以滿足使用者的需求。
3. 一部分同學可以開發測試案例
4. 在現有版本的基礎上做漸進式開發
   1. 理解需求 （這個時候理解了客戶需求是什麼）
   2. 設計
   3. 開發
   4. 迴歸測試 （用到上面開發的測試案例）

 負擔問題

很多學生一聽說我給他們安排的學習計劃, 第一個反應往往是 - 負擔太重了!  讓我們回到健身館,  如果一個體質正常的青年想健美, 教練安排他舉杠鈴, 他會說什麼呢 – “杠鈴太重, 我走了!” 

負擔是相對的, 這要看大家要跟誰比了。 我在清華大學上課的時候, 也有學生反映“負擔太重”, 我只好和他們一起回憶清華大學校長及各級領導提出來的目標 – “建設世界一流大學" .  如果要建設世界一流大學, 那要跟世界一流大學比。  在軟體和軟體工程方面世界一流的大學是哪一家呢? 我想唯有跟卡內基·梅隆大學 (CMU) 相比,  才能不辱沒清華大學的名聲。

CMU 有一門本科生的課 - Build Virtual World,   是由已故的Randy Pausch 教授講授的, 我們可以比較一下。

CMU – Build Virtual World	現代軟體工程
5 projects/semester 2 week/project, done by 4 person team Rotate team member in each project	4 project/semester:      1 Idividual Proj.       2 Pair Proj.       1 Team Proj.    team project has 6 people.  rotate team member in each project.

他們一個學期要做 5 個項目, 我們只做 4 個。誰的負擔重?

所以, 不是我要為難大家, 而是校領導的意思， 同學們可以找校領導說 – 我們不想成為世界一流大學, 成為五道口一帶的二流大學就可以了。 如果領導同意了, 我當然可以降低負擔, 而且我還可以把師生關係調整為 “哥們/哥們”, 要混還不容易嗎?!

我們可以看看古代的曆史,  為古羅馬帝國開拓疆土計程車兵, 他們是如何培訓的呢?  請選擇:

a) 他們不經過培訓, 直接上戰場

b) 他們只學理論, 沒有實戰

c) 他們用比實戰更輕的武器訓練

d) 他們用和實戰一樣重的武器訓練

e) 他們用比實戰重一倍的武器訓練

先別說成為世界級計程車兵或將軍, 如果大家想在戰場上活得比別人長, 你會選哪一項呢?   

這個道理對IT 行業的學生也是一樣的, 在人潮洶湧的招聘市場, 我們可以問一下那些學生 -

你平時在學校裡是如何為將來的職業準備的?

a) 不經過準備, 直接上

b) 只學理論, 沒有實戰

c) 用比實際工作要求更低的水平訓練

d) 用和實際工作一樣的要求訓練

e) 用比實際工作高一倍的要求訓練

在這片神奇的土地上, 我們或許還可以聽到 f) 的回答:

f) 我不用準備, 我爹叫阿剛。 

  如何判分

“分, 分, 學生的命根。 ”

我在剛開始教這門課的時候, 我看到助教給同學們的作業判分是這樣的模式:

最好的作業10分, 次好的9.5, 然後依次平滑下降, 有些學生交作業很遲, 有些學生寫的程式都不能編譯, 這些學生都得到6分左右。

這樣的分數體系看起來非常和諧, 但這不是軟體業的實際情況.  我們任選一種軟體類型,  例如文書處理軟體, 最好的軟體在市場上有多少份額? 第二名佔有多少?  第三名呢? 第四名? 誰知道文書處理軟體市場的第四名是誰? 搜尋引擎呢?  第一名的佔有率是多少? 第二, 第三, 第四呢?  第四名的軟體也是由優秀的軟體人員開發的, 他們也許加班更多,  那為什麼只有那麼少的份額? 這公平麼?

由於軟體市場有 ”贏者通吃” 的規律 (第一名會佔據 50% 以上的份額),  我們在訓練中也要體現這一規律. 所以我規定:

如果大家做同樣類型的作業， 則採用以下規則:

完成品質在第一檔次的同學(一個或多個), 得滿分。

完成品質在第二檔次的同學, 得 1/2 的分。

在第三檔次的同學, 得1/3 的分數。

以此類推…

在很多作業中,  我或TA會寫一個比較平庸的解法 (例如用冒泡排序或線性尋找)參加作業評比。 這個平庸的作業會得0分, 那比這個還差的作業, 就會得負分,  從-1, –2, –3 類推下去.  下面是兩個評分體系的比較:

這樣公平麼?  很多人會問。  如果一個同學寫了沒有任何bug 的程式, 得到10分, 另外的同學程式有 1 個bug, 得到9.5 分, 程式編譯都不過的同學, 也得6分, 那你覺得這樣對寫了全對程式的同學公平麼?  如果一個同學的程式連普通的冒泡排序都比不過, 老師和TA在花時間陪他玩,  他欠我們分數, 這樣的人不得負分得什麼?

做中學

上《現代軟體工程》 的同學, 都是大三到研一的同學,  應該具備基本的學習能力和開發能力,  軟體工程和其他類的工程 (如航天工程, 化學工程) 不一樣, 我們每天都可以用到軟體工程的產物 (軟體),  搭建, 學習一個軟體開發平台比航天化工要容易很多 (注: 在自家後院放二踢腳不是航天工程), 相關的學習資料也是非常容易獲得。 在這個情況下,  學生們可以在“做”的過程中學習, 這也叫”做中學”.  做了, 有疑問, 再問老師, 問專家, 這樣學習的效果會好很多。 我為這門課準備了三本課本, 一本指定的閱讀教材, 二十本參考書 (對, 20 本), 同學們平時可以多看書。

真實的項目

在這門課中, 我鼓勵學生做自己決定的項目, 但是要求他們要做”真實的項目” – 有真正使用者的軟體。  那些 “經典” 的項目, 例書館管理系統, 學生學籍管理系統等, 是不符合我的要求的。  項目要有活的使用者, 只有活的使用者才有活的需求, 才有活的情境, 活的測試案例。 只有活的使用者才決定同學們寫的軟體是否值得使用, 有些團隊寫的小軟體很好用,  在合適的使用者群中引起共鳴, 短短時間內, 就會有幾千到幾萬個使用者 (像北航團隊開發的魔方程式), 也有的團隊費了老鼻子勁, 寫出來的東西使用者量小於10, 自己團隊成員包括在內。 這些不同的使用者數量會迫使項目團隊反思當初在需求分析, 設計上的問題。 另外這門課並不是演算法競賽, 或者代碼集中營, 大家比的不是如何快速敲打出某個演算法, 而是如何在有限的時間內交付有價值的軟體給特定的使用者。 “真實”這一條件也促使大家做 “現實”的項目和專案管理。 很多學生有宏大的夢想,  但是在短短的 8 周Team 專案時間內, 甚至短短的 16 周課程時間內, 他們發現宏大的構想被自己程式的bug 搞得千瘡百孔， 轟然倒地。 

 學生的收穫

在這門課裡, 有付出, 就會有收穫, 收穫體現在下列方面:

1. 寫出一個可用的, 有實際使用者的軟體。 這對大多數人來說, 是第一次。
2. 完整體驗軟體生命週期, 對於生命週期的各個階段有實際的瞭解。對於軟體設計有實際的掌握。 對敏捷式軟體開發 (Agile Software Development)的具體技術有實踐能力。
3. 瞭解軟體團隊的各個角色, 和各個角色的互動.  對於其中一個角色有實際的深入體驗。
4. 學習如何與不同的角色打交道, 培養團隊精神, 學會解決衝突的幾種方法

這個課程不講什麼?  這個課程不具體講某一個程式設計語言, 也不講 UML, 設計模式。 這些內容都應該屬於其它課程。

但是從課後的自我反饋來看, 學生往往在某一門“程式設計語言”很有收穫, 為什麼呢?  第一是因為這門課的個人項目和結對項目讓他們有充分的機會學習和鞏固關於某一語言的知識;  另外, 他們第一次把某一門語言用到了一個有分量的實際項目中去, 從而深入地瞭解這個語言的特性。這可以說是<現代軟體工程> 的一個好的副作用。

任何一門課都不會一帆風順地講下來, 所有人皆大歡喜。 老師學生需要時間來適應，交流,  才能逐步提高。 吹了這麼多, 到底學生反映如何? 下面是清華大學的學生對這門課的不記名評價。

評分內容	2007	2008	2009
熱情、認真、投入、嚴謹，教書育人	95.45±3.80	95.00±3.42	98.90±2.21
講課思路清晰，重點、痛點突出	94.55±4.04	89.29±5.77	98.90±2.21
講解生動、有吸引力，能激發學生的求知慾	92.73±5.15	90.71±5.37	98.91±2.21
師生互動，鼓勵學生質疑，並給予思路的引導	94.55±4.04	93.57±3.69	98.91±2.21
提供或推薦的教學資料有助於學生學習	93.64±4.23	86.43±8.19	99.00±2.21
作業等課程訓練有利於課程內容的學習	94.55±4.04	90.00±4.95	99.00±2.21
考核及評價方式能激勵學生主動學習與鑽研	92.73±5.15	87.86±4.88	97.89±3.04
注重學生創新意識和獨立思考能力的培養	92.73±4.37	91.43±4.44	98.91±2.21
對學生課外學習給予指導、建議	92.73±4.37	91.43±4.92	99.00±2.21
學習本門課程後有收穫	92.73±4.37	90.00±5.38	97.91±3.04

上好課很難, 老師, 學生都不容易, 這個部落格講了一些。

一些學生清澈的， 充滿求知慾的眼神告訴我, 他們最關心的是 -

                怎麼用最小的代價, 讓我過了這門課!

上了這門課就知道代價了。