對大學 IT 專業教育的回報

[這是2009 年 寫的文章, 一部分收集到 <IT 小小鳥> 這本書裡了。 這兩天看到軟體學院同學對教學的回報,  看來好些問題都沒有得到解決。 教育部門時不時會開教學研讨會, 去世界有名的大學, 公司參觀, 他們還要參觀多少年?  他們會請已經畢業的學生來提意見麼? 學生要年複一年地等它變好? ]

[原帖: http://yishan.cc/blogs/xin/archive/2009/08/19/it.aspx]

中國的大學生教育體系中，大約有10% 的學生屬于 IT 相關的專業 (計算機科學，軟體，MIS，電子工程, 軟體工程，等)。 這些學生畢業之後，就成為IT 産業的從業者或使用者，他們是IT 行業的希望。 這些學生在接受了 4-6 年的教育之後，對這個教育系統有什麼回報呢? 我問了一些剛剛畢業的軟體專業的同學，軟體教育迫切要改變的做法是什麼? 下面是一些回答：

*** 同學們想說什麼 ***

a) 實踐! 軟體教育離不開實踐，不要太強調閉卷考試， 老師一定要讓學生實踐，實習。給一個真實的客戶做項目和自己幻想一個需求來做項目是有很大差別的。自己從頭寫程式和維護别人寫的代碼是有很大差別的。 沒有真實的需求，沒有軟體的增量開發，沒有團隊合作，程式設計和軟體工程中的大部分理論都淪為空談。

b) 講為什麼! 學生上了很多課，反而覺得很迷茫，這些課的意義是什麼? 為什麼有這麼多的原理，資料結構, 紅的樹，黑的樹，模式和算法? 不知道我學的東西有什麼用，怎麼用。老師似乎不想告訴我們這些課程在實踐中的意義 (或者他們也沒實踐過? )。學生隻有死記硬背來應付考試，考試後全忘記。

c) 打好基礎，其他自學! 好好學基礎課，特别是算法, 資料結構, 編譯原理，作業系統 。 其他課的内容用到了自己學就可以了。

d) IT 教育不光是代碼! 軟體教育不是孤立體，希望在軟體教育中把文科的知識聯系進來，和設計聯系起來; 把軟體/IT 行業有趣的發展曆史放進來 (講講圖靈，馮·諾依曼，講講Smalltalk, 各種語言的源和流)。培養學生對這個行業的興趣、熱情和敏感。 提倡互動，介紹同學上相關的論壇，網站，開拓視野。

[建議大家看 《浪潮之巅》]

*** 我看到的現象 ***

由于工作的關系，我在過去的幾年中通路了十多所軟體學院或計算機學院，和不少老師，學生座談過。我在微軟亞洲研究院裡也接觸了來自各個學校的學生，談得多了，就有下面的一些想法。這裡我主要談計算機軟體的教育。

想來的人來不了

學校裡都是按照聯考/考研的成績決定專業去向，我聽到一些喜歡玩遊戲的學生特别想來軟體學院，但是由于成績不夠好，來不了。 一些成績挺好的學生優先選擇了軟體專業，因為大家都說這個專業好找工作。 但是到了快畢業的時候才發現 不對勁， 于是有人後悔： “其實我不喜歡寫程式，我想轉行。” 咳，如果你的位置留給當初那些喜歡玩遊戲的學生該多好。

教務處的規定

老師反映說，本來想鍛煉同學的團隊協作精神，期末大作業讓同學們分組合作完成一個項目，但是沒想到教務處不同意。 教務處堅持大作業必須每個同學單獨做，不能搞團隊協作，其理由是團隊協作之後，有人就會偷懶！

其實，讓學生一個人去做，他/她也有可能去糊弄，抄襲。 而且正因為缺少協作，一個人不能完成很高品質的軟體，單幹的同學更有可能去抄。 最後老師争不過教務處，隻好讓每個同學單獨做一個項目了事，一個普通學生很難做完一個項目，怎麼辦? 那隻好 “參考” 别人的東西，有人負責測試麼? 沒有。這也是每個班的四五十個學生作業隻有4-5 個版本的原因之一。這麼多項目，老師能一一仔細審閱麼? 顯然也不行。 但是這事教務處的規定，就這麼糊弄過去吧。 據說在一些學校裡，教務處非常強勢，能決定老師的績效考核。

知識和技能

很多人認為，大學是傳授知識的地方。很多知識 (Knowledge)可以講授，同學們也可以自己查找，學習。 例如程式設計語言的一些邊邊角角的規定，在工作中如果忘了，那就現查資料，或者寫一個測試程式驗證一下。 但是技能 (Skill) 則要通過實際的反複訓練，才能獲得，并優化。 我看到同學們經常能夠背誦 “在設計中應該高内聚，低耦合”， 但是在實際中根本不知道如何應用。 就如同大家都可以在理論上掌握如何下圍棋 - “要讓每一步占領全局最有價值的要點”， 但是在實戰中下的棋卻支離破碎，潰不成軍。

我們在考試的時候，能不能少考一些死的知識，而多考一些技能？ 學校裡能練習什麼技能呢？很多：

• 自己學習的能力 （能不能自己學習一門語言，然後應用？ 為什麼非得先要老師講解？）
• 了解别人的意思和動機 (inter-personal awareness)
• 表達自己想法的能力 （不妨從做 PPT 示範開始）
• 說服，影響同伴的能力 （大家一起合作，如何能讓團隊按自己的想法前進?）
• 制定計劃，并執行計劃的能力 （是自己的計劃，而不是老師給訂的計劃）
• 總結，改進的能力 （一個項目之後，能否心平氣和地總結，改進？）

更多關于知識, 技能, 和技能的反面:

技能的反面 - 魔方和模仿

基礎知識很紮實 - 但是面試就是做不出來, 怎麼辦?

學校教育的目的

有一年, 我教的一個班是大三的學生, 他們反映課程壓力很大 (同時上編譯原理, 資料庫等), 我跟系裡建議是否把軟體工程挪到大四去上, 這樣他們學的資料庫知識能更好地用上. 系裡的老師列出了很多擔心, 其中最重要的一點是 - 學生們大四的時候要考研, 是以不能上太累的課, 要讓他們有時間為考研複習！ 我們談論了許久, 我終于明白系裡面在選擇“讓學生上有意義的課” 和 "讓學生有時間準備考研" 兩者之間, 選擇了後者。 其實天朝學校的目的大抵如此 - 讓學生順利地升入下一個階段, 就完事兒了。 在這種思想指導下:

國小六年級開始複習, 準備小升初; 

初三開始複習, 準備升高中; 

高三開始複習, 準備升大學; 

大四開始複習, 準備考研;

有些同學還要花很多時間準備考一個 “國考”.

最後, 學生到了社會上, 發現再也沒有考試了, 要靠真本事, 怎麼辦? 學校可曾教過他們?

老師們, 你們可曾真的教過學生 “銳意改革, 開拓創新”?

想創新, 如何教創新

到大學裡聽上司的報告，你會聽到很多次 “創新”和與“創新”相關的詞彙。 你覺得這個學校的上司的确非常想創新。 但是另一方面，我聽到一些同學反映教材，教案，教學方法都是幾年甚至十多年不變的老一套，和實際非常脫節。 難道老師們不想在教學上創新麼? 後來有比較了解内情的人跟我說，現在軟體相關的專業非常熱門，畢業前景也不錯，一些計算機系的老師能拿到不少項目，資金也不少， 老師和上司都忙着開公司去了。他們為什麼要在教學上創新? 重用幾年前的教案不也這樣過來了麼?!

在軟體學院裡，怎麼教創新? 除了讓學生打下堅實的專業基礎之外，學校可以做的一件事就是 -

允許學生實驗，失敗，再實驗，再失敗。

我不用重複愛迪生經過幾千次失敗才發明可以實用的電燈的故事了，創新不是公式推導，不是一旦學好例題，就能模仿炮制的解題方法。 要給同學們試驗和失敗的機會。 有人問 - 學生失敗了，課程怎麼給分呢？ 如果同學們能夠認真總結經驗。同樣也可以得到比較好的分數。 這些同學真正到了工作中， 以前失敗經驗教訓就能幫助他們更好地創新。我在給學生上《軟體工程》課程的時候的評分标準大緻是：

1. 有創新的想法，并成功實作，優。
2. 有創新的想法，但是失敗了，能認真總結，優。
3. 無創新的想法，能成功地實作平庸的計劃。 良好。

一些關于創新的部落格:

創新 - 王屋村的魔方們

IT 行業的創新 - 創新的迷思

清一色

一方面，計算機系和軟體學院的各年級學生年齡一樣，背景一樣。 老師像種莊稼一樣，一茬一茬的播種和收割。每次課程和作業，同學們都是從頭開始。大家懂得一樣多, 大家都是理工科學生的思維。

一些軟體學院收了雙證的學生後，情況好了一些，畢竟有一些别的行業，别的經曆的同學進來了。這些人組成的團隊能互相取長補短，對學生們很有幫助。 我建議要盡量打破 “清一色” 的配置模式， 很多學校有 “工業設計” 等設計類專業，“經濟管理”等管理類專業，他們其實可以在學校裡就和軟體專業的學生一起上課, 做項目, 拿學分。

三文魚模型

很多學生在學校裡認真學習了很多軟體知識，在同學中間也很牛的樣子，于是他們躊躇滿志地畢業了。 但是到了工作機關，他們發現項目組中老中青，各種背景的人都有。 沒有人請自己從頭設計全新的軟體， 自己得從讀别人的代碼，維護軟體系統上手。 我在《移山之道》 這本書裡寫過 “三文魚模型”：

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

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

1. 需求分析：學生們都不懂企業的需求是什麼，上課睡覺。

2. 設計階段：學生們畫了許多 UML 圖，用設計工具畫了各種形狀的圖形，僅此而已。

3. 實作階段：學生們開始熱烈讨論，UML 圖早已經扔到一邊。

4. 穩定階段：學生們中十分之一的人開始寫代碼，其他人不知道在幹什麼．代碼大部分情況下都不能工作，所有設計過的種種黑箱和白箱測試都無從開始。

5. 釋出階段：這個階段隻有一天時間，就是最後檢查的那一天，同時還有人在調試程式．

6. 維護階段：課程結束了，同學們對自己的産品沒有任何維護，放假了!

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

阿超沉吟半晌，說，事實上，一個軟體工程師在現實世界中的職業發展好像和瀑布相反：

1. 畢業進入公司，開始維護一些已有的軟體（維護階段）

2. 能夠在項目中改一些bug，然後釋出小規模的更新版本 （穩定/釋出階段）

3. 負責重寫一個小小的子產品，沒有文檔，寫很多代碼（實作階段）

如果做得還可以, 就會進入下一階段：

4. 有機會設計比較大的子產品，自己寫一些文檔 （設計階段）