關於程式設計課程之規劃

尊敬的唐政委您好:
這篇長文與資訊領域的教學有關。
我正擔任某國立大學資訊工程學系大一程式設計課程的助教,最近在教學的現場中,對系上的課程規劃、老師的教學approach、我們與同學的互動等面向,都感到相當的乏力。
我不確定您是否知曉國內一般資訊相關科系的大一新鮮人所受的程式課程訓練狀況,所以請恕我在這裡先囉唆地描述。特別以資訊工程系來說,教學幾乎都是以C語言為主。我所看過的教學approach不外乎兩種,1. 投影片lecturing:講解語法、觀念、例題(簡單演算法)等2. (由教師本人)邊實作邊講解,輔佐以詳細的紙本講義作為課後/離線時的參考而考核方面,大致上有兩種方式(依系所規劃可能有混用的形式):1. 出題目,要求學生透過FTP之類的方式上傳作業2. 在電腦教室進行,現場提供題目的上機測試。
接下來我想描述我前段所謂「乏力感」所指為何。1. 指定C語言的意義C語言之所以被許多系所定為「本系學生的母語」,甚至常有「他們資管只會python沒關係,不會C還叫什麼資工系學生」之老生常談,我認為是因為C語言被認為「相當低階,可完整掌握電腦行為」的緣故。但是我攻讀至今,常常在想這樣的評論是否也是某種「過來人」的偏見,因為很明顯可以想像的到更早些年,眾人無法滿足於編譯器技術的最佳化之前,想必也有類似「他們業餘玩家學XXX,我們當然要寫assembly」之類的說法。也就是說我認為,所謂「低階」這樣的標準,應該是可以隨著時代的演進而有相應的改變的。其次,「可以較佳地掌握電腦行為」這樣的教學目的,我認為相當合理,畢竟C是類UNIX世界的系統語言標準。然而系上在多年前先是砍去「資訊工程導論」一門課,之後又砍去「系統程式」一門課,「作業系統」通常使用骨灰級的Nachos專案作教材,問題是那也是C++開發的,而「計算機組織/架構」這樣的抽象層已經在C語言之下了。「學習C語言」能夠「掌握電腦行為」的教學目的放在整體課程規劃之中頓時有種失焦感;這是我們系特有的情形,也許其他學校不會如此。
若想要推動這方面的改變,我人微言輕,目前也不敢妄想去挑戰那個巨大風車。只是一些可能會面臨的阻礙,也是有思考過的,比方說「學習C可以更方便學習其他語言,先學其他語言之後未必能夠回來寫C這麼低階的語言」這樣的說法,我認為撇除適應新語法、跨典範(比方說functional vs imperative)的門檻,根本就沒有這樣的問題,否則何以許多學校仍然有assembly課程在較高年級?也不見其被當人數超過大一程式設計。
2. 考核的方式我們的考核方法,要求學生在限時之內「不准查看資料」、「不准合作」的條件下解決給定的題目。我認為這都是很荒謬的事情。
先論「不准查看資料」一節。學習是大腦這個精密的機器在下至潛意識上至意識之間進行的工作,幾乎其他所有領域的學習,都來自大量的領域內知識觀察(由外至內)、還有練習(自發反饋):廚師是觀察師傅的各個細節處理、參考食譜、自行掌握味道等一連串的修行;寫作文也是遍覽群書才能成一家之言。我們每週派發給學生們的練習題(無須繳交、不佔分數)頂多也就五六題,現場上機測驗時基於「不希望同學抄code」的理由禁止同學們攜帶程式碼作為參考,固然使得沒有認真練習的學生沒有東西可以參考,卻同時扼殺了認真的同學想要在自己先前建立的基礎上面對新挑戰的可能。
「不准合作」。我們在大學之前的教育就注重競爭,這對於甫進入大學的新鮮人來說也是根深蒂固的慣習。但是合作已經幾乎是當世代最重要的普遍能力,如政委您在g0v的倡議與行動、jserv鼓吹大家要努力「打群架」等,都相當強調合作的重要。現階段的考核方式,表面上看來是考場內禁止抄襲的堂堂正正的規定,實際上也間接扼殺了考場外合作的可能。理想的情況,應該要設計一種考核制度使得這些學生可以如同候鳥飛行一般共同增長能力,但以我們學校的學生能力而言,通常一班60~80人不等,其中約有2~3人是資訊能手,10數人雖是新手但在學習上相當輕鬆,剩下中等程度最多,而後是少數幾乎必然低空飛過等待高年級之後才會開竅的同學。其中只有那最少數的資訊能手能夠簡單面對限時的上機考,即使是那10數名fast learner也可能因為緊張或不熟悉而馬失前蹄,所以考場外的練習時,他們就沒有強大的誘因幫助其他同學增進學習上的理解,畢竟現有的制度底下,幫助別的同學會使得他們更有可能會無法取得成績評等的優勢。
3. 最重要的能力?由上節延伸,我甚感疑惑的是,這樣的程式設計究竟是不是這個時代的資訊人最重要的能力?
從考核的方式可以得知系所要求學生磨練出的能力是,alone、from scratch的能力,然而並不是所有學生都需要這樣為了程式競賽選手設計的高強度訓練,事實也證明了我們一屆超過百名學生,參加競賽者頂多兩隻手可數。並且無論選手或非選手,日後都需要合作,也都幾乎不可能「從頭開始」任何實際有用的專案。
在批評的反面,若要我提出建設性的建議,由我個人看何謂可以讓資訊新手培養的「最重要的能力」,那麼我想正應該讓學生打從最一開始就領略「自學」的重要性:由程式語言開始自學吧!目前網路上已經有無數的學習資源,以GO語言為例則還有像是Go Play Ground那樣的闖關式自學網站,而自學所需要的前置能力,首推英文,或是現有的學校老師(或是我們助)也可以作些在地化,以銜接新手的學習。我認為將程式語言由上至下的學習典範改為自學的模式可以大幅減少老師與研究生的心力耗費,因為我們每週備課和考核的時間都非常可觀,為此不得不付出其他創新研究的機會成本。此外我認為次重要的是「利用既有資源的能力」,這理應能從前一階段的自學中獲得動力與需求,因為必然會需要有可以諮詢的對象,也會更有動力提早學習使用stackoverflow這類的技術集中地。(題外話,我曾聽某個工程師朋友說自己沒有stackoverflow就不會寫程式了)再來就是「合作力」,這應該要以在課程中增加團隊型專案為考核標準的方式來執行,學生們在這條件下就能自發地學習版本控制,並對於軟體工程議題較有切身體會。
4. 教/學之間綜上所述,我認為學習就是觀摩和練習。
程式設計學習中的觀摩面向,比較前段提及的兩種上課方法與自學:自學需自行培養兩種能力,雖然不能避免打混的情況出現,但一來同時有其他課程需要程式設計能力,會強迫學生加速自學步調,二來系上有畢業的門檻標準,也是上機考形式)。投影片教學就是是教條陳列講座,所能放入投影片的程式碼也不多,教師若是願意在上課時邊講邊coding,則觀摩的密度會提昇許多。
練習的面向則比較目前的課後練習方法與自學:以工具而言,若能找到或提供一個良好設計的平台(如go play ground、try haskell),則現代化的網頁設計應該能夠給予自學者良好的回饋以提昇學習動力。現行模式運用Online Judge系統的練習也不錯,主要的關鍵應該還是學習者自己的動機強烈與否。
終於來到結語的部份,目前為止我描述了作為助教,在程式設計這樣的基礎科目的教學現場感受到無力的部份,橫跨低至程式語言選擇高至教學策略制定的抽象層幅度,希望本文沒有浪費政委您的時間。
國家所需要的資訊技術力及其人力,目前科班生大抵都是透過我所描述的情境所培育出來的,其他補習班的管道我因為沒有經驗就不予評論。我擅自測度資訊能力的累積應該會逐漸成為國家重要的發展策略之一,因此儘管是這樣看似學校甚至系所尺度的小事,我仍然試圖做了這一份夾帶我個人想法的簡略報告。
在此情況下,我特別想要參考身為數位政委的您的看法。因為您既有程式語言設計及在這個時代以技術力結合公民領域的經驗,又在政府中擔任具有未來性的角色。感謝您閱讀至此,我很期待您的回應。

感謝您的詳細說明。雖然大學教育並非我的業務範圍,但強調競爭力的文化,與強調合作能力的文化,在教與學的過程裡,會自然形成不同的取向。
單以程式設計來說,我很高興網路社群發展至今,已經可以提供學習者多樣的選擇進路。
同樣的,最近在協調電競議題時,對於致力於這門技藝的專業人才,我們能如何將「動手實作及創意思考」融入學習環境,進而培養合作文化、增進社會公共性,我想也會是值得重視的面向。