軟體工程課程教育的一點想法

標籤：

  大學本科的軟體工程課程一直遵循瀑布型的為線索的各個裡程碑的相關知識點的展開介紹，現在多有理論架構與實踐能力孰重孰輕之爭。這裡我也有一點點自己的看法。

       軟體工程在項目開發教學中的作用實質上類似電腦導論在電腦教育中的學科地位，應當屬於前置性，線索性，架構式介紹，細思量其內容之廣、理論之重、實踐之繁的教學之繁重，本身就不是一個學期能承載得了的。既然教學大綱只安排一個學期，充其量，將來慢慢發展應當只是領學習者進門的而一個入門學科而已。而不是有些人說的那麼危及及乎的想法。

      站在更高一些的高度，比如體系架構或者整個IT業高度，或者整個知識體系更高的高度來看。軟體工程，只是前人的經驗總結，前輩們總結失敗與成功的經驗，藉助了其他工程的思想來指導項目的開發而已，並不能說明這種就方法是真理絕對正確，這個理論也還在不斷完善、推翻和重新整理的過程。這個方法也許只是在一定的範圍內可行，但並不表示其絕對的正確。正如愛因斯坦相對論對牛頓定律，當物體速度達到光速，牛頓定律並不適用了。

        而現在軟體業高度，深度，廣度日新月異的發展，想用一套並不完全成熟理論來定義和約束，還要硬塞進學生的大腦，顯然是狹隘的，也是可笑的。

     其一、軟體工程思想只是前人總結的經驗，並不是多麼有高度的絕對真理。數學的集合理論尚有駁論，更何況所謂的軟體工程思想。軟體工程課可以手把手教學生用這個方法來開發一個項目，但是絕對不是逼著學生們一定要如此來做才是正確，殊途同歸，也許聰明的學生會想出更有辦法的方法來達到同樣的目的，又為何不可呢？所以對於現在的本科學生教育的軟體工程所謂的在學中做，我個人是不太贊同的。容易犯了把學生的思路和開拓性框死的彎路，其實可以鼓勵學生不同組採用不同的模式和架構來開發，也鼓勵小組長們採用不同的管理方式，學期末的時候，討論各種不同方法的優劣，引導學生在失敗中吸取教訓，而不是直接告訴他們什麼是對，什麼是錯。因為應用的學科本身就沒有對錯之分。

      其二，軟體工程到底應該偏理論還是偏實踐呢？其實需要區分學生的所在專業的，有的專業是電腦方面學科，軟體工程只是三年級的一門專業課，有的專業是軟體工程專業，軟體工程課則是專業基礎課，二者有著本質的不同。而且光靠一門軟體工程課教會學生軟體產品開發，是一種本末倒置的想法。如果要讓學生會軟體產品開發，可以在軟工後續加修一門專案管理或產品開發類的選修課或者開設實踐基地，學生按照興趣選擇不同類型的項目，理論結合實際，讓企業來指導的不同類型軟體產品開發。所以我個人認為軟體工程課應該是偏向理論與標準的學習、文檔的撰寫等，雖然理論課枯燥，不能為了引導學生的興趣就盲目降低理論的要求，本身大學教育就不在於引導興趣（理論上來說高中填報志願就應當預設學生選擇了自己感興趣的學科），而是引導學生更多的挖掘自學能力、解決問題的能力，鑽研理論的能力，建立高屋建瓴的思想，無論將來是從事項目開發還是科學研究都打下堅實的基礎。

       把軟體產品開發實踐教學硬揉入軟體工程課，有脆化軟體工程課理論部分之嫌，而且學生容易一葉障目。只有一個學期的時間，時間非常緊，學生從事開發充其量只看到一種方法，只開發了一種項目，難以見到整片森林，白白耽誤了大好的學習和博覽群書的時間。軟體產品開發和軟體工程理論，雖然關係緊密，但是他們猶如樹葉和樹根的關係，產品開發和專案管理的方法有很多，但是其根本的理論精髓是簡單的規律性的東西，他們之間關係應該是現象與本質、形與神的關係，如果只教會了本科學生軟體開發的“形”，而忽略了軟工思想靈魂的“神”的傳達，完全是本末倒置，自以為是的想法。

       其三，教育應該是一種可持續的教育，而不是“應試”教育。把理論厚重，任重而道遠的軟體工程課，上成了一種很有趣的，項目開發課，看似皆大歡喜，滿足了同學的“學會技能”的假象，其實對學生的可持續發展能力是令人擔憂的。沒有理論鋪墊，只是學會了一兩種方法，看似會開發軟體產品了，其實項目換個架構、換個語言、換個環境，很可能這個學生沒有理論的指導，只怕是從頭開始學習，重新摸索。這樣的學生後續難以有可持續的學習和進展的可能，若干年後可能還是必須搬出大學的“軟體工程”理論書重新學習，才能解其“饑渴”。

     我多年教學中軟體工程課，發現學習最認真的是專升本專業的那些學生。因為這樣的班級大多的學生都有開發工作的經驗，在企業工作了幾年，重新回來學習，對軟體工程的想法完全不同。記得2014年的一屆學生，一個同學的表現特別突出，軟工課特別認真，對課上布置的文檔撰寫任務非常認真，小小的一個項目，需求文檔寫了上百頁，認真畫每一個UML圖，細緻入微，自覺加班加點，對任何一個理論都充滿了興趣鑽研和實踐，作為小組長撰寫了非常正規的小組管理規章和規約，而且自己制定了一整套的管理制度，因為同學們都服他，經過他同意那個小組後來陸續加入到15名同學，針對不同層次他就自己發明了分階梯的管理方式。他經常會找機會與我課後聊天，瞭解到，其實他是專科畢業後在北京一家軟體公司工作了好幾年，從事軟體工程師的工作，他說那幾年他深刻體會軟體工程的重要，他甚至沒有機會接觸到需求報告和概要設計的撰寫，現在回來讀書，居然可以做項目組長，完全自由發揮的寫需求和設計文檔，是他夢寐以求的事情，沒日沒夜的學習和撰寫，然後學習如何管理小組內不同的人，學習如何把自己頭腦中的想法轉換為制度，轉換為文檔，如何傳達給其他組員等等，他說他感謝那個學期的課完成了他的夢想。那個學期的課，後半學期的實驗課，都交給這個同學來組織全班小組之間的項目開發方法的討論，因為我當時實驗課允許小組用任何方法來實現項目開發，理論課依然是則介紹軟體工程思想，至於小組用與不用悉聽尊便。後來每節實驗課都由這位同學來共同組織大家的討論，比較不同小組的每周的進展程度，每個小組總結自己的失敗與成功，互相探討，鼓勵互相爭論。有些小組代碼能力強很快就開發完項目，不寫文檔，我就會在期中的時候，修改他們的需求，換掉他們最強的代碼開發的同學，讓他們體會不寫文檔的痛苦，事後自覺補寫文檔，防止我隨時修改需求和換人的舉動。

      當然，我終歸還是一個心軟的老師，只要有參加實驗討論，只要有做實驗，筆試只要及格，所有的同學都會通過考試。我認為，學習重在體驗，考核並不重要。人只要經曆了，總是會留下印象的，這比什麼都重要，這個過程中學會的東西，比分數重要的多。我的打分標準是，所有的小組長都是90分以上，無論小組做的怎麼樣，因為在我的班裡，小組長一定是付出最多的，我採用的是組長負責制，組員完全歸組長來教育和組織，分數也有20%是由組長來打分。

     最後提一點關於 敏捷方法，我認為敏捷方法只是教會開發人員一種思想高度合作的工作方式，其實其中很多工作方式並不適用於中國國情，生搬硬套的教育學生必須結對程式設計，站立會議，形如填鴨，缺乏開拓思想。有些人應用的好，是因為他的思維方式適應敏捷方法，並不表示這個方法有多麼科學，我認為應該針對中國國情，尊重現實情況，找到一條屬於我們國家自己的一種敏捷方式，應該啟發學生對於“思維合作”有更多自己喜歡的方式，鼓勵孩子們學習的同時，嘗試走一條屬於自己的路。

       總之，我認為，大學就是一個允許讓學生們犯錯的地方，通過犯錯同時學習理論而不斷總結經驗的地方，而不是老師教育對和錯的地方。大學應該是一個讓學生犯錯的同時，學習理論，自己判斷跌倒是否與不採納理論有關，是否可以有自己更好的方法，避免將來走彎路等，老師的作用只是告訴學生理論是什麼，是否是真理，理論是否正確應該讓學生自己去探索和實踐，作為老師不能按一己之見而下定論。所謂的用“軟體開發教學來作為軟體工程課”，究其實質是填鴨似的，只讓學生知曉所謂的簡單線條理論，生搬硬套的放入實踐，疲於奔命的大量作業，最後發現學生和老師都很疲憊，學生也失去了在大學期間能博覽群書的珍貴時光，也失去了理論指導實踐，實踐上升到理論總結的科學方法論。

軟體工程課程教育的一點想法