你的抄襲有包含學習嗎？

May 04 04:35~17:26

 

前兩周花了五個小時的上課時間review同學的程式作業，這學期只有七個同學修「軟體生命週期管理」，人數很少所以可以利用上課時間詳細的和學生討論程式內容。經過兩周「地毯式」的討論，發現全班七個人所寫的程式可以分成三大類，人數分布剛好是2-2-1。前兩個分類裡面的兩位同學，只要把類別名稱重新命名一下，程式的結構基本上是相同的。

發現這個現象之後Teddy開玩笑地說：「被我抓到抄襲了喔」。聽到抄襲二字學生奮力反駁，表示程式雖然看起來有點像但是內容細節有許多不同之處。

Teddy告訴學生：

「其實我一點也不在乎你們是否抄襲同學的程式作業，因為『抄襲』本來就是軟體開發不可分割的一部分。寫程式遇到問題的時候怎麼辦？就拜一下Google大神或到Stack Overflow上找資料，然後把找到的範例程式直接複製、貼上，最後略做修改變成自己軟體的一部分，這是很正常的行為。就算你抄襲同學作業甚至請同學幫你寫（一種外包的概念！？）都沒關係，只要你有能力可以在我跟你review作業的時候解釋你的程式為什麼這樣設計並且沒被問倒就可以了。否則，就算全部的程式都是你寫的，看起來也可以動，但你卻無法回答為什麼要這樣做，那也是白搭。」

***

以前念書的時候有些程式設計課程的助教很負責，改作業時會特別用心抓抄襲，而且非常自豪自己抓抄襲的功力高強。但現在想想如果抄襲行為可以經過加值之後「升級」成為一種學習，也沒什麼不好。從學術的角度來看，給定出處的「抄襲」就叫做「引用」（引用是否合理另當別論）。從學生學習的角度來看，最大的問題應該是在於傳統上班級人數太多，以及老師、助教 能力 時間有限，所以無法一對一當面檢視學生的程式作業（加上學生自己也不長進XD），只好透過間接的方式來打成績。這種「間接溝通方式」或「透過文件溝通方式」從敏捷開發的角度來看，都不是很好的學習回饋機制。但現實上逐一面對面review會花掉太多時間，Teddy光是和七位同學review一次作業就花了五個小時，的確是「成本很高」的學習方式。

學生抄襲作業問題不大，最大的問題在於過程中只有無腦抄襲，而沒有用腦學習。

***

友藏內心獨白：不要只當鸚鵡。