※ 引述《pest (這些分鐘妳有沒有想過我?)》之銘言： : 我觀察到美國的程式設計課搭配很多的助教，甚至可以達到 6 個學生對 1 個助教 : 的程度。上課教授講得口沫橫飛，不懂的話下課就去找助教；我也有同學因為進度 : 真的跟不上，系上特別安排一位助教只指導她。 : 現實上，台灣的公立學校要做到這樣的編制困難重重。 : 因為助教人數夠多，所以教授出作業就可以放膽去出，反正有這麼多助教可以協助。 : 練習的量夠多，學的就紮實。 : 不過，光是助教多並不會提升學生程式的品質；程式的品質還要靠自動化的 : 測試把關。在這門課中，學生繳交的作業是上傳後自動批改的，學生除了要寫 : 主程式之外，還必須要上傳自己寫的 test case，test case 的覆蓋率不達 : 一定比例則不予評分；連自己 test case 都過不了的就更不用說了。 : 自我驗證完之後，評分系統會跑助教或教授寫的 test case，這時候大部份人 : 的程式都原形畢露得回去改過；等到改到全通過，基本的概念差不多都很清楚了。 ========== 先不管助教是否人多, 就我所知過去的作法(還沒有宿網的時代)通常有兩種方式: 1.上機實習, 先是照課本自敲一個例子, 在時限內完成, 然後給個習題配合 著改範例產生所要的結果, 有問題就找助教發問(可以是舉手助教到, 或是 用網路教學平台與教師共用顯示幕或遠端遙控). 在專科這種方式常流於照打範例, 照做就算實習了. 2.上機做作業. 實習課當場講解題目要求, 人各一機各自解題, 結束時交結果, 或者請助教看結果. 也可以是讀共同的輸入資料檔, 將結果寫到指定的檔名, 並上傳程式到指定目錄與檔名. 到宿網時代, 有些就是帶回去自己做, 然後到教室展示結果給助教看, 不然就 是有誤, 需讓助教當場解疑或更正錯誤. 通常, 助教只能先看結果, 等有空才能解疑除錯. 碰上多數是錯的, 雙方就只 能兩瞪眼, 不知要挑那個先解起. 最後就演變成助教講解習題答案. 問題就出在學生就是寫出個錯的, 或者說不會寫, 然後不會的人又很多, 權宜 下就是給答案. 如果照老式的一再延到下次做出來才交, 能全數習題做出來的就很少. 通常是那句老話 : 人多勢眾, 有恃無恐. : 最後一關是壓力測試，學生寫的函式不能比助教寫的慢。看到一堆人為了多一個 : if 或多宣告一個變數而斤斤計較，實在覺得訓練出來品質當然有差。 : 如果連教授都對於軟體品質控管付諸行動，在這樣耳濡目染下的學生，進到業界 用 test case 做要求與示範會是展現軟體工程的好辦法. 但現在多數碰到的是 相互觀望, 死給你看. 老師與助教太嚴, 都怨氣藉口一堆, 都先反應在對老師的 評量上, 任課老師也只能抓尾巴的少數砍, 沒有帶上強烈的學習動機, 也逼不上 多數人的能力. 欠缺學習意願與動機, 一直都是台灣這種程設課的明顯特徵. : 當然會比沒有經過這樣訓練的學生要有很多優勢。更不用說助教事後還會依據 : 註解和風格給分了。相較之下，台灣的程式設計課程真的還在未開發國家的時代。 : 雖然現實是，學問做得好跟寫程式沒什麼關係，認真作研究大概也沒什麼時間 : 寫這類工具來開程式設計課，不過，如果往上一點來看，資工高年級開的這麼 : 多課，難道就不能以撰寫這些工具作為期末專題嗎? 軟體工程課、程式語言、 : Compiler、Pattern Recognition (用來抓抄襲), 這些技術和知識都在教授 : 腦中，但大家就是沒想過要拿它們來 "實用" 在學生身上。一念之差，對於 : 課程的品質，自然也就天差地遠了。 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.115.4.12