※ 引述《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