多元化程式設計教學研究計畫

(1)

教育部教學實踐研究計畫成果報告

Project Report for MOE Teaching Practice Research Program

計畫編號 / Project Number：PEE1080114

學門專案分類 / Division：工程

執行期間 / Funding Period：108 學年度 (108/08/01 – 109/07/31)

多元化程式設計教學研究計畫

配合課程：資料結構

計算機程式設計物件導向程式設計物件導向程式設計實習

計畫主持人(Principal Investigator)：戴文凱

執行機構及系所(Institution / Department / Program)：

國立臺灣科技大學資訊工程學系成果報告公開日期：

■立即公開 □延後公開(統一於 2022 年 9 月 30 日公開) 繳交報告日期(Report Submission Date)：2020/09/02

(2)

《目錄》

壹、 計畫執行內容 ... 1

一、研究動機與主題目的 ... 1

(一) 教學實踐研究計畫動機 ... 1

(二) 教學實踐研究計畫主題及研究目的 ... 1

二、文獻探討 ... 2

(一) 多元化教學 ... 2

(二) 程式設計的概念與實作 ... 2

(三) 數位訓練暨競賽平台 ... 2

(四) 助教團隊協同教學 ... 3

三、研究問題 ... 3

四、研究設計與方法 ... 3

(一) 研究設計說明 ... 3

(二) 研究步驟說明 ... 6

五、教學暨研究成果 ... 8

(一) 學生測驗成績 ... 8

(二) 課程問卷調查 ... 9

六、建議與省思 ... 10

貳、 參考文獻 ... 11

參、 附件... 12

一、計畫研究架構圖 ... 12

二、課程進度表 ... 12

三、成績統計圖表 ... 14

四、學生教學意見回饋 ... 16

五、學生專案互評 ... 20

(3)

《圖目錄》

圖 1：線上問答系統「Quizizz」操作方式 ... 5

圖 2：Google Sheets (左)與 Google Forms (右) ... 5

圖 3：Online Judge 介面圖 ... 7

圖 4：物件導向程式設計—作業成績平均 ... 8

圖 5：物件導向程式設計—作業成績標準差 ... 8

圖 6：期中考—成績人數分布 ... 9

圖 7：期末考—成績人數分布 ... 9

圖 8：研究架構圖 ... 12

圖 9：物件導向程式設計實習—作業成績平均 ... 14

圖 10：物件導向程式設計實習—作業成績標準差 ... 14

圖 11：物件導向程式設計實習—期末專案成績人數分布 ... 15

圖 12：期中考—各題答題狀況 ... 15

圖 13：期末考—各題答題狀況 ... 15

(4)

《表目錄》

表 1：物件導向程式設計—期中問卷統計表（部分） ... 9

表 2：物件導向程式設計—期末問卷統計表（部分） ... 10

表 3：計算機程式設計各週課程進度表 ... 13

表 4：物件導向程式設計各週課程進度表 ... 14

表 5：物件導向程式設計—期中問卷統計全表 ... 16

表 6：物件導向程式設計實習—期中問卷統計全表 ... 17

表 7：物件導向程式設計—期末問卷統計全表 ... 18

表 8：物件導向程式設計實習—期末問卷統計全表 ... 19

表 9：學生專案互評成果 1 ... 22

表 10：學生專案互評成果 2 ... 24

(5)

壹、 計畫執行內容

一、研究動機與主題目的

(一) 教學實踐研究計畫動機

在大學的程式設計課程中，有著來自各種不同背景的學生，如普通高中升學，或是來自高職的電機、資訊等科系；在這些學生中，有些對程式設計有一定程度的了解，有些從未接觸過程式設計，有些從小就開始學習程式設計，甚至參加過程式設計比賽。在每位學生的基礎都不同的情況下，如何找到平衡點，讓每位學生都能夠依照自己的情況、自己的步調來進行學習，是目前程式設計課程面臨的問題。

而程式設計是一個需要大量的邏輯思考來實現的技術，因此不像其他理論課程，經由教師在台上指導或是學生自行閱讀書籍就能夠理解，它需要經過大量的實作練習，累積經驗、加強邏輯觀念，方能學會。也因此許多沒有基礎的學生需要有大量時間的練習，才能跟上進度，在練習過程中也可能會因為覺得枯燥乏味或是無法理解而影響學習進度，甚至想要放棄；若減緩教學速度則會影響其他學生的學習權益。

因此若要讓學生都能有良好的學習成效，我們必須制定一個有系統的程式設計課程教學計畫，藉此讓學生能在有趣的學習環境下，快速的上手程式設計。

(二) 教學實踐研究計畫主題及研究目的

本計畫透過多元化的教學方法，來解決上述之教學問題，如藉由有系統的題目練習與挑戰，讓學生漸進式的進行實作練習；藉由競賽、遊戲等方法，讓學生在有趣的環境下學習；透過助教教學、線上提問，來輔導進度較慢的學生。因此本計畫提出以下方法，讓每位學生都能有更好的學習環境、更高的學習意願：

1. 案例教學

2. 題目難易度分類 3. 相似題型練習 4. 關卡式題型挑戰 5. 自動化測試正確性 6. 分組競賽

7. 遊戲模式

8. 大量助教協同教學 9. 線上解答系統

(6)

二、文獻探討

(一) 多元化教學

隨著新知識的產生成指數成長，獲取知識的途徑和教學的方式也愈來愈多樣。然而，教學方法種類繁多，各有其特性和優缺點。根據學生的需要，選擇數種適合的教學方法就顯得非常重要(李嵩賢，2004)，而此方式稱之為多元化教學。

(二) 程式設計的概念與實作

在程式設計教學中，概念和練習是兩個不可分割且同等重要的學習目標(Anna Eckerdal，2009)。對於剛開始學習程式設計的學生來說，一個普遍的困難點是區分類別(class)和物件(object)。如果在課堂範例中，對於每一個類別，都只生成一個物件的話，很明顯的會造成理解上的困難。要避免這個情況，對於同一類別，總是生成多個不同物件是比較好的方式(Michael Thun´e，2005)，從以上的例子可以看出” 量”對於學習的影響。另外研究顯示愈輕易愈快速學習到的知識，

也愈容易遺忘，因此我們需要透過練習使得學習過程具有挑戰性並付出努力，

以達到長效的學習(Pooja K. Agarwal，2013)。本計畫以線上解題系統(Online Judge)作為平台，經由每周實習課的練習題實作，與正課理論相互對照，加深印象。

本計畫使用線上解題系統，學生能即時檢測自己的成果。在實習課堂中，

若在解題過程中碰到任何問題，助教們也會在一旁為其解惑，確認學生了解正確的觀念和實作流程(陳峰津，1993)。

(三) 數位訓練暨競賽平台

經由線上數位平台，學生能依自己的步調自由的學習，並根據需求和興趣來決定個人的學習路徑。同時數位平台的學習內容也可以和教授的課程、個人作業、和組別課題相整合(Food and Agriculture Organization，2011)。線上平台提供多樣的教學可能，包括：以學生為學習的中心、強烈的參與感、輕鬆的使用全球資源、透過多媒體的呈現達到經驗學習、不便於來到課堂的特殊學生也能參與、提高學生的學習興趣(Mya Poe，2002)。

線上解題系統(Online Judge)設計為能夠可靠的評估使用者提交的演算法原始碼，使其在同質的環境下進行下一步的編譯和測試，有下列的好處：第一，

教師能夠更準確的評斷學生程式碼的正確性。一旦教師通過題目的定義準備了能照顧到所有邊角案例的完整測試集，接受錯誤答案的機率幾乎可以被忽略。

第二，評測所需時間大幅縮短，因此教師能準備並分配更多的練習給學生。第三，學生能幾乎在瞬間得知自己的答案正確與否(Szymon Wasik，2017)。

除了用於作業練習之外，線上解題系統亦用於程式設計競賽，如 ACM ICPC(International Collegiate Programming Contest)。顯然按照字面上的解釋，

程式設計競賽是一個具有競爭性的活動，會有贏家的產生。通常它可以被視作

(7)

且在準備競賽時，牽涉許多分工合作。事實上，訓練過程牽涉一些與真正競爭無關的有趣的學習策略，可以對於學生的養成有非常正面的影響，且或許能夠中和人們印象中競爭式學習的負面影響(Miguel Revilla，2008)。

(四) 助教團隊協同教學

助教應該在程式設計實習課中來回漫步，並視個別學生所需提供協助 (Byron S. Gottfried，1996)。在本計畫的實習課中，共有八到十位的助教，教學的工作亦可以透過分工來提升效率，例如登記分數、檢查個別程式碼錯誤、講解特定內容、更新線上解題系統、出題目等等，以促進互助合作。協同教學使每一個學生能夠較高效率地獲得指導，單一助教也得以減輕工作量。

一對一教育能夠適應學生個別差異，但成本較高，且忽略了同儕間的互助。

而班級教學卻又忽略了個別學生的差異。協同教學配合學習的需求，從大班級授課、組別內成員相互討論、到個別學生自行撰寫程式，兼顧了個性發展和團體互助之長(方炳林，普通教學法)。

三、研究問題

面對來自各領域及程度不同的學生，有時會造成課程難以進行，例如：本科系學生可能有高中前即早已接觸程式設計，然而同時存在學生從未撰寫過任何程式。部分教師會根據每屆學生狀況對課程進行些微調整，然而此一方法不但使教師備課負擔加重，協助課程之助教也相對較為辛苦。另外，基礎程式課技課堂常有電機、資管等非資工本科系之學生進行修課，程式基礎相對較弱的學生在專題實作上可能會感到困難。本計畫透過多元教學方法，除了希望提升學生成績，也期望學生在課堂中發掘程式設計的有趣之處，提供學習動機與提升興趣。

四、研究設計與方法

(一) 研究設計說明

1. 教學目標

(1) 計算機程式設計：

⚫ 對 C 語言透徹的了解。

⚫ 能夠寫出正確且有效率的 C 語言，並有完善的註解。

⚫ 能夠有效地學習程式設計的高階技巧。

(2) 物件導向程式設計：

⚫ 對 C++語言透徹的了解。

⚫ 能夠有效地學習程式設計的高階技巧。

⚫ 理解物件導向的觀念

⚫ 學會使用重要的 C++技術，如 composition of objects、operator overloads、

dynamic memory allocation、inheritance and polymorphism、file I/O、

exception handling、templates、bitwise operations、preprocessor directives、

basic data structures 等等。

⚫ 能夠寫出正確且有效率的 C++語言，並有完善的註解。

(8)

2. 教學方法

課程分為程式設計正課與實習課。正課為教師進行教學，並且每週出數題程式設計題目供學生回家練習；實習課則為課程當中進行程式設計實作練習，並有數名助教協助學習。且結合以下多元化教學方法：

⚫ 案例教學：透過模擬實際情況與事件，來加強學生對於各種題型的解題應變能力，並提升學生在實際應用程式設計於真實情境與工作的技巧。

例如平時作業中大多以敘事方式描述之應用問題出題。期末專題實作則是執行較大型的專案，讓學生提早了解合作撰寫程式的重要性。

⚫ 題目難易度分類：在練習題與期中考、期末考中，將題目的難易度分為簡單、中等、困難；藉由此種難度分類方式，培養學生對於題目的掌握度，如應該分配多少時間在此難度的練習題上。也藉此讓學生了解國際程式設計考試與比賽的進行模式。

⚫ 相似題型練習：為了讓學生更加熟悉解題方法，在練習題中將選擇學生較弱之題型，每種題型皆有數題難度不同之相似題目，學生藉由理解此題型中較易的題目了解解法後，即可再進行難度更高的相似題型練習，如此反覆練習，使學生更熟能生巧。

⚫ 關卡式題型挑戰：練習題的難度會隨著學生的答題正確率、速度，或是教學進度等因素而逐漸提升，例如學期初會以簡單的判斷、迴圈等運用當作練習題，並隨著課程進度逐漸加入遞迴、指標等等；期中考後題目會更加複雜與靈活，需要結合多種觀念才能夠實作出來。藉由此方式讓學生漸進式的練習，讓學習更有成效。

⚫ 自動化測試正確性：建立一個可以自動測試程式正確性的系統—Online Judge，學生只要將程式碼上傳至系統之對應題目，即可立即得知該題是否有錯誤、錯誤的原因等等，並且將答題狀況記錄於系統中。此方法不僅可以節省傳統人工檢查時消耗的時間、也能避免檢查錯誤的情況發生。

⚫ 分組競賽：學生針對期末專題進行互評，各小組簡述在專案中遇到的困難、解決辦法、討論紀錄等等，並對其他組別進行評價。透過這樣的互相評比，讓了解自己的不足之處，提升學習成效。

⚫ 遊戲模式：人往往會對覺得有趣的事物更加投入，針對程式觀念而非撰寫技巧，在線上問答系統「Quizizz」上回答題目，在遊戲化作答中體驗競爭感。並制定配合相似題型練習之獎懲機制：

1. 學生於遊戲過程中可看到排名。

2. 每次測驗 10 題，共兩次，皆於期中考前。

3. 答對題數 5 題以上，當周相似題型作業 3 題。(同平時)

4. 答對題數小於 5 題，當周相似題型作業 5 題。(新增 2 題難度中或中偏難之題目)

(9)

圖 1：線上問答系統「Quizizz」操作方式

⚫ 大量助教協同教學：在一對多的教學課程當中，學生可能會有無法理解的情況發生，卻因怕影響教學進度或不敢提問而影響學習成效。本計劃課堂中將至少有 8 位助教協助教學，每位助教根據課堂發問與回家後的線上發問，就能夠了解每位學生的學習狀況，給予更合適的協助。

⚫ 線上解答系統：為了在學生回家後得到及時幫助，配合助教建立多管道之線上解答系統，除了可直接寄信詢問助教問題外，另外建立如

Google Sheets/Forms 形式之公開提問，學生於表單填寫問題後，助教將於公開表格提供問題回覆；若同學還有問題可於表格後進行追問，直到解決問題。

圖 2：Google Sheets (左)與 Google Forms (右)

(10)

3. 成績考核方式

(1) 計算機程式設計：

⚫ 程式設計作業 20%

⚫ 期中考試 40%

⚫ 期末考試 40%

⚫ 期中考與期末考形式：上機考 (2) 計算機程式設計實習：

⚫ 課程中實作練習題 32%

◼ 期中考前，每週出三題程式設計題，題目難度分為簡單、中等、

困難，每題一分，每位學生自行解題(可以詢問助教)。需在課堂當天午夜前繳交。助教將於繳交期限過後，公佈解答於數位學習平台給學生當典範參考。

◼ 期中考後，同學分組執行專案撰寫，並與助教進行線上問答。

⚫ 期中考與期末考形式：上機考 (3) 物件導向程式設計：

⚫ 程式設計作業 20%

⚫ 期中考與期末考形式：上機考 (4) 物件導向程式設計實習：

⚫ 程式設計作業及出席率 25%

⚫ 專案 30%

◼ 期中考前，每週出三題程式設計題，題目難度分為簡單、中等、

困難，每位學生自行解題，助教僅提供了解題意和錯誤程式的修改方向。並以 Online Judge 進行自動評測，且需在當週日午夜前繳交。助教將於繳交期限過後，公佈解答於數位學習平台給學生當典範參考。

◼ 期中考後，同學分組執行專案撰寫，一組 2 人，並與助教進行線上問答。

⚫ 期中考與期末考形式：上機考 (二) 研究步驟說明

1. 研究架構

本研究課程分為程式設計正課與實習課。正課為教師進行教學，並且每週出數題程式設計題目作業；實習課則為課程當中進行程式設計實作練習，

(11)

並有數名助教協助學習。課程結束後透過成績考核與問卷調查等方式，評估學生學習成效與課程意見。

2. 研究範圍

⚫ 課程範疇：本課程將教學 C、C++兩種程式語言，並且分為正課與實習課；教學內容主要為 C、C++基本觀念、輸入輸出、判斷式、迴圈、

陣列、指標等程式設計相關技術。

⚫ 評量方式：本計劃之評量方式分為正課作業與實習課練習題、期中考與期末考、專案。

3. 研究對象

本研究對象為國立臺灣科技大學資訊工程系、全校不分系學士班一年級學生，其中對於程式設計的了解有以下幾種情形：

⚫ 從未接觸過程式設計。

⚫ 尚未修習過程式設計課程，但有自學經驗。

⚫ 修習過程式設計課程，對程式設計有一定程度的了解。

⚫ 對程式設計非常熟悉，且參加過程式設計比賽。

4. 研究方法及工具

本研究使用兩種方法及工具進行教學研究成效之檢視，分別為：

(1) Online Judge

學生作答完，將程式上傳至 Online Judge 即可自動測式程式是否正確，節省人工檢測之時間，並讓學生了解答題狀況與可改善的地方。

圖 3：Online Judge 介面圖

(2) 課程問卷調查

本研究之課程問卷調查由學生在接受程式設計正課與實習課程後填答，問卷內容包含：對於本課程是否有學習興趣、教學進度是否適中、難易度是否適中、練習題命題是否合宜、使用之系統是否合宜、

教學之優缺點及其他具體建議等。

(12)

五、教學暨研究成果

(一) 學生測驗成績

依據本計畫之執行結果，學生成績約在期中過後呈現大幅變化，以課程「物件導向程式設計」為例，結果如下：

圖 4：物件導向程式設計—作業成績平均

圖 5：物件導向程式設計—作業成績標準差

由圖表可看到第七次以前之作業成績皆呈現比較穩定的狀態，然而隨著題目難度上升，學生整體成績下降且標準差提高，可見本計畫之「題目難易度分類」確實有達到區分難度的效果。

學生之期中、期末考結果如下：

(13)

圖 6：期中考—成績人數分布

圖 7：期末考—成績人數分布

由上圖可見期中考成績之結果較趨近於標準分布，符合本計畫於學期中偏向難度適中的出題；而期末考學生的成績整體偏低，推測除了題目整體提高至中偏難的程度以外，出題類型也從基本題增加更多應用問題。

(二) 課程問卷調查 1. 期中教學意見

以課程「物件導向程式設計」為例，期中結果如下：

項目 填答人次

1. 到目前為止我對這門 課程的學習興趣

非常有興趣有興趣無意見沒興趣非常沒興趣

14 23 8 1 1

2. 到目前為止我覺得本課程之教學進度適中

非常同意同意普通不同意非常不同意

11 17 17 2 0

3. 目前為止我覺得本課程之內容

太困難稍難難易適中稍易太容易

3 22 22 0 0

4. 到目前為止我覺得本課程之負擔

太重稍嫌太重恰到好處輕鬆非常輕鬆

4 20 21 2 0

表 1：物件導向程式設計—期中問卷統計表（部分）

(14)

由上表可知過半同學於期中時仍抱持著「對本課程有興趣」、「課程教學進度適中」、「課程難度尚可」以及「課程負擔尚可」的評價。

2. 期末教學意見

本計畫期末時進行教學回饋調查，「物件導向程式設計」之結果如下：

填答人次

項目\分數 5 分 4 分 3 分 2 分 1 分平均

1. 教學內容及進度之適切性 31 19 7 1 0 4.38

2. 作業、考試和授課內容之適切性 25 16 12 3 2 4.02

3. 助教回答問題、批改作業及對我學習之幫助 24 17 12 4 1 4.02

4. 實習設備及維護滿足實習需求 21 13 13 5 6 3.66

表 2：物件導向程式設計—期末問卷統計表（部分）

上表項目 1 及 2 中可看到學生的學習體驗整體而言相當優良，且由項目 3 可知學生對於本計畫提供之大量助教協同教學對學生確實有實質幫助。分數最低的項目 4，學生除了對授課及考試的設備進行分數評價，亦有部分學生於「其他建設性意見」中說明希望更新考試硬體設備。此部分雖非本計畫之研究項目，由於設備的好壞將直接影響學生的學習成效，因此本項目也將視為未來教學項目的重要考量。

六、建議與省思

(一) Online Judge 管理與使用

本計劃課程初次使用 Online Judge (OJ)進行自動評測，除了系統本身可能出現小錯誤外，亦要考量學生使用自動評測系統的適應性，包含 error log 的判讀以及避免利用投機作弊的方式使用系統而限制繳交次數等等。這對題目撰寫而言是在自由度降低的前提下保持解題效率，卻不一定是所有學生都能適應的學習方式。

(二) 助教協同教學

雖然多數同學於回饋單中表示大量助教協助確實有助於學習，然而助教群的管理也同時是教學挑戰的一環。例如出題時應確保題目品質與正確性、以及進行 OJ 管理時題目的可行性確認，等等因素皆可能影響學生的學習狀況。

(三) 未來教學建議

本計畫執行過程中相當依賴大量助教，然而人多也容易導致品質不一，作業出題若產生瑕疵或甚至助教群對於題目的認知不同，學生容易感到困惑且信心下降。應讓授課教師與助教群互相監督幫助，藉此維持教學品質，盡可能降低系統的使用困難性與例外狀況。另外需督促學校設備之更新汰換，減少未來學生面對自動化考試時的設備問題，進而影響學習成果。

(15)

貳、 參考文獻

[1] 李嵩賢(2004)。T&D 飛訊第二十八期，多元化的教學方法。

[2] 陳峰津(1993)。教育方法論。台北巿：三民。

[3] 方炳林(1992)。普通教學法。台北巿：三民。

[4] Anna Eckerdal (2009). Novice Programming Students' Learning of Concepts and Practise.

[5] Byron S. Gottfried (1997). Teaching Computer Programming Effectively Using Active Learning.

[6] Food and Agriculture Organization of the United Nations (2011). E-learning methodologies, A guide for designing and developing e-learning courses.

[7] Mya Poe, Martha L. A. (2002). Teaching and Learning Online, Communication, Community, and Assessment.

[8] Szymon Wasik, Maciej Antczak, Jan Badura, Artur Laskowski, Tomasz Sternal (2016). A Survey on Online Judge Systems and Their Applications.

[9] Miguel A. Revilla, Shahriar Manzoor, Rujia Liu (2008). Competitive Learning in Informatics: The UVa Online Judge Experience.

(16)

參、附件

一、計畫研究架構圖

圖 8：研究架構圖

二、課程進度表

(一) 計算機程式設計：

週次授課內容與活動

第 1 週 Basic Features of C Introducing C C Fundamentals

第 2 週 FormattedInput/Output Expressions

第 3 週 Selection Statements 第 4 週 Loops

第 5 週 Basic Types 第 6 週 Arrays 第 7 週 Functions

第 8 週 Program Organization 第 9 週 Mid-Term Examination

(17)

第 10 週 Advanced Features of C Pointers

Pointers and Arrays 第 11 週 Strings

第 12 週 ThePreprocessor

Writing LargePrograms

第 13 週 Structures, Unions, and Enumerations 第 14 週 Advanced Uses of Pointers

第 15 週 Declarations ProgramDesign

Low-LevelProgramming 第 16 週 The Standard C Library

Input/Output 第 17 週 Error Handling 第 18 週 Final Examination

表 3：計算機程式設計各週課程進度表

(二) 物件導向程式設計：

週次授課內容與活動

第 1 週 Course Introduction Introduction to C++

Basics/Flow of Control 第 2 週 Function Basics

Parameters and Overloading 第 3 週 Arrays

第 4 週 Structures and Classes

第 5 週 Constructors and Other Tools 第 6 週 Operator Overloading, Friends

References 第 7 週 Strings

第 8 週 Pointers and Dynamic Arrays 第 9 週 Mid-Term Examination 第 10 週 Streams and File I/O 第 11 週 Recursion

第 12 週 Inheritance

第 13 週 Polymorphism and Virtual Functions 第 14 週 Templates

第 15 週 Exception Handling

第 16 週 Standard Template Library

(18)

第 17 週 Patterns and UML 第 18 週 Final Examination

表 4：物件導向程式設計各週課程進度表

三、成績統計圖表

圖 9：物件導向程式設計實習—作業成績平均

圖 10：物件導向程式設計實習—作業成績標準差

(19)

圖 11：物件導向程式設計實習—期末專案成績人數分布

圖 12：期中考—各題答題狀況

圖 13：期末考—各題答題狀況

(20)

四、學生教學意見回饋

(一) 期中教學回饋

表 5：物件導向程式設計—期中問卷統計全表

1. 到目前為止我對這門課 程的學習興趣

14 23 8 1 1

11 17 17 2 0

3 22 22 0 0

4 20 21 2 0

我覺得這門課最好的部分：

老師說明詳細

老師非常棒功課岀得剛剛好全部

淺顯易懂舉例眾多生活的例子讓大家了解本課的精隨老師上課幽默風趣，不會太死，願意讓學生問問題

強大的助教群老師講課很認真每年都有改教材修第三次惹真的覺得老師越講越好作業太多學分太少

老師超用心教學。

有精美講義可以看，老師教得很好！

老師教的很好也很用心回答學生的疑問教授講解很清楚

對本課程其他具體建議：

希望作業可以有簡單提示

老師有時候講有點快，希望課後問問題的時間可以長一點希望教室的電腦能夠不再跳出重新開機訊息

遠距錄影很好覺得可以全部錄起來放在網路上

希望老師可以請助教在出題目的時候就把規則和要求講清楚，不然每次都害我們浪費時間從 OJ 推答案是什麼，或需要寫信問助教才能搞懂題目在問什麼、要我們做什麼。

希望期中考出得有鑑別度，而不是出得很難考倒全部學生。有鑑別度的測驗才是好的考試。

希望老師多教一點東西～

可以測超過兩次嗎

(21)

表 6：物件導向程式設計實習—期中問卷統計全表

1. 到目前為止我對這門課 程的學習興趣

12 25 4 0 2

12 14 16 1 0

2 22 19 0 0

2 20 19 2 0

我覺得這門課最好的部分：

老師上課超級認真，可以學習到很多，口條清晰老師講解

老師教的超級棒史上最喜歡的一堂課練習與觀念檢討

能夠無限次數測 OJ 老師講話有趣

老師幽默風趣，上課不會太死，也願意適時讓學生問問題。

教授講課簡單易懂，貼近生活

助教認真快速仔細地回答我們各種(可能很笨又不知道笨在哪裡)的問題，謝謝你們！

企業實用看重的部分

大部分助教解答時都很詳細且用心大量實習和深入的內容

實習課同學相互討論學習 對本課程其他具體建議：

我認為助教在出題時的題目闡述不夠清楚，有時候看不太懂助教到底想要的是什麼，然後建議以後題目用 pdf 因為 word 跑格式跑得很嚴重，output sample 很難看

學分給多一點一分的課花最多時間上課速度有點太快

教室的椅子間寬度希望能夠大至讓使用者自由通行 1.這幾個禮拜的題目比較複雜，沒辦法在課堂內完成。

2.希望有天 OJ 的錯誤訊息排版會更好看，現在的有點難對齊自己錯在哪裡。

OJ 系統請改進

(22)

(二) 期末教學回饋

填答人次

項目\分數 5 分 4 分 3 分 2 分 1 分 平均

壹、教學相關事項

1. 任課教師充分準備教材 42 11 4 0 1 4.60

2. 教師表達方式與啟發性 43 10 4 0 1 4.62

3. 教學內容及進度之適切性 31 19 7 1 0 4.38

4. 作業、考試和授課內容之適切性 25 16 12 3 2 4.02

5. 教師之整體教學成效 36 15 5 1 1 4.45

貳、教學資源相關事項

7. 實習設備及維護滿足實習需求 21 13 13 5 6 3.66

參、其他具建設性之意見 老師用心學生安心

非常棒的老師助教也非常棒教授教學有趣很會講課

教授的授課滿分講得清楚深入淺出下課也對學生的問題回答詳細且用心但是關於期中期末考的部分上機考試的電腦太爛有時候程式還會無法回應考試的部份給學生太大的壓力不懂為什麼都用線上評比了還限制學生答題檢測的次數考試應該是評斷學生的學習狀況而不是讓學生搞的神經兮兮原本平常都會的程式在考試時因為次數而無法好好發揮理論上來說一個程式應該是可以反覆測試的吧不論在學校或是在業界我不覺得限制學生答題次數是個好作法希望能改進

作業跟課程內容可以更有相關性一點電腦設備太差

期中考上機考，學校電腦超慢，以為沒按到上傳按鍵，差點一次上傳 2 次，還好 ac

謝謝老師很用心教，但有時候可能有些太快了，一次太多有點難消化。另外希望考試可以多給一點上傳機會，有時候會出現一些沒有在作業遇到的錯誤，不知道該怎麼解但沒有多的測試機會。

考試偏難。電腦教室的 Visual Studio 編譯要花 30 秒，執行也要花 30 秒。

表 7：物件導向程式設計—期末問卷統計全表

(23)

填答人次

項目\分數 5 分 4 分 3 分 2 分 1 分 平均

壹、教學相關事項

1. 任課教師充分準備教材 33 11 4 1 1 4.48

2. 教師表達方式與啟發性 33 13 2 1 1 4.52

3. 教學內容及進度之適切性 26 14 6 3 1 4.22

4. 作業、考試和授課內容之適切性 21 12 12 3 2 3.94

5. 教師之整體教學成效 28 14 6 1 1 4.34

貳、教學資源相關事項

7. 實習設備及維護滿足實習需求 12 11 14 5 7 3.33

參、其他具建設性之意見

計中的電腦如果在程式執行速度上提升，考試答題的比例也許就會跟著提升 TA 日常要求我們通靈

我遇過最棒的程式老師

學校的設備該更新了程式跑很慢 OJ 有時候會搞人如：WA 全白

助教於遠距時很用心開了表單讓我們可以問問題，盡快瞭解要如何改善。

期中只能測兩次太少了

電算中心 509 的電腦超級慢，期中考考試的時候開偵錯模式電腦就開始當，常常要重開 VS。聽說其他間都沒這些問題。

電算中心電腦超級爛堂堂台科大資訊工程系的電腦編譯執行按下去還會當掉助教在作業出題時常常沒有命題完善 OJ 系統的測試資料也跟命題不符導致學生需要反覆跟助教確認或是自己摸索題目的用意有時候問問題還會被助教旋轉反問ㄏㄏ

老師教的太快了電腦教室設備太差

表 8：物件導向程式設計實習—期末問卷統計全表

(24)

五、學生專案互評

(一) 組別成果一

自評

組員：B10732001 B10732015

請簡述你在執行專案過程中遇到的問題：

1.要在 main 函式內直接讀取角色、怪物等檔案(txt)

解法：有別於以往的透過 cin 讀取，因為是第一次使用這樣的方式，剛開始還蠻摸不著頭緒的，於是我們上網搜尋，發現從 main 的屬性內調整即可，比想像

中容易。

2. 怪物須先由地圖讀取依序賦予代號，再依據人數調整，最後放置對應的怪物 解法：先依序賦予怪物代號，再將該回合未出現怪物隱藏。

3. 尚未顯示(隱藏地圖裡)的怪物不應被放入怪物抽牌容器 解法：設定變數判斷怪物為顯示或是隱藏狀態

4. Check 指令可以發生在角色動作選擇之後且能重複觸發

解法：使用 count 只記錄出牌、長休這兩個動作的次數，忽略 check，當 count 等於存活角色數量時結束 while 迴圈。

5. 專案整合

我們一開始是將角色/怪物/地圖等部分分開撰寫程式碼，後來在整合成一個專案時，遇到了不少困難，例如檔案間參數的傳遞及讀取。

解法：我們在 main 裡面統一設定容器及函式，集中管理各項跟遊戲執行時互動的物件，避免掉檔案彼此呼叫時的疑難雜症。

討論記錄：

5/13 討論工作分配林杰翰：地圖陳藝安：角色+怪物 5/19 驗收 5/13 林杰翰 21:56 目前已經處理好 input 的資料

5/16 陳藝安完成角色 Character 物件 5/16 陳藝安完成怪物 Monster 物件 5/21 陳藝安 PlayCharacter

5/22 陳藝安 PlayMonster & 遊戲流程(缺敏捷值比較) 5/26 現階段剩餘工作分配

5/28 陳藝安遊戲流程角色執行階段(缺敏捷值二次比較) 角色和怪物的物件有重大變更(代號) 最新版檔案:0528

6/1 陳藝安遊戲流程(缺 check 檢查所有存活角色及怪物) 最新版 0601

6/4 林杰翰地圖顯示(可視地區)正確、move 移動(角色和怪物都可以用同一個)、

選擇角色們的初始位置、門的功能、能正確判斷結束時機(22:13)

目前剩下「遠程攻擊計算正確」、「敵人鎖定目標正確」、「視野判斷正確」

6/5 陳藝安將 monsterData.h 的 vector<monster>data 移至 public, moster 補上 setELITE

6/5 林杰翰 monster 針對 Player 數目更改的功能撰寫完畢 6/8,9Debug

6/10 完成專案

小組互評第一組

組員：B10815027 B10815029

(25)

優點：

第二十七組的專題使用圖像介面，比原先的 cmd 介面更清晰，用顏色區別地板、牆等物是個好想法，不僅在操作時能一目瞭然，也能一改 cmd 灰階的土氣。而能自由讀取選擇地圖、角色怪物等資料十分方便。在選牌階段，選牌確認後點選 OK 的部分讓玩家操作更便捷，也有選牌張數超出指定數量的例外排除，功能完善。我們認為羅列手牌及棄牌堆的設計十分不錯，讓玩家更清楚目前的情況。另外，透過點擊搭配藍色框框列出可移動的範圍，在角色移動方面也是很棒的設計。

缺點：

遊戲介面整體偏灰，顏色較單調，在沒有看說明手冊或影片時難以理解遊戲操作及顯示資訊。

而怪物方塊上的白色字體有些不清楚，卡牌的敏捷值也位於最下圖層，加上淡藍色有些不清楚，敏捷值是卡牌的重要資訊之一，應多加注意。在角色資訊欄位的部分，淡黃色底搭配小字體略為不明顯，使玩家的操作體驗下降不少。輪到該角色的紅色提示框框，可用其他方式（例如閃爍）將目標更醒目的展現；角色、怪物互動等資訊以小視窗展現，較顯得不清楚。

最後在遊戲結束畫面（勝利、失敗）階段略為簡陋，有損整體圖形介面之觀感。

改進建議：

可多加利用黑色牆壁，套用成其他顏色之色塊，讓遊戲本身的背景更豐富。

角色卡牌的部分能做得更細緻，設計卡牌邊框或自訂義字體都能大幅提升卡片的精緻程度。

在操作介面可加入更多提示及教學，或是能內嵌遊戲說明，使玩家更快了解遊戲、深入淺出。

可將過去近幾個發生的角色、怪物動作以清單的方式顯示在側欄，方便玩家檢索及參考。

血量、攻擊力、護甲值等數值能加入圖示，增添遊戲豐富度及易讀性。

小組互評第二組

組員：B10815001 B10815023 優點：

1.使用圖像介面，畫面清晰

2.右方有資料可供對照，避免錯誤 3.自行設計圖案、通關畫面

4.左上角可自行輸入檔案名稱 5.隨時可查看手牌和棄牌堆 缺點：

1.右邊的文字視窗會擋住遊戲 2.右邊的文字太過冗長需要移動

3.用自己研發的測資較難從影片中發現 bug 改進建議：

1.右側視窗可以改得大一點 2.輸出需要換行，增進閱讀性 3.在影片中也同時拍攝範例測資 4.背景可改為較為亮麗的顏色

(26)

小組互評第三組

組員：B10732011 B10732025 優點：

1.影片經過剪輯，雖無說話但呈現清楚 DEBUGMODE 2.影片結尾祝福每位在水深火熱的學生們，相當溫馨

3.將老師上課的名言佳句收錄並放置影片中，證明兩位同學是認真上課的 缺點：

1.一次開門就將全部的門打開，感覺不太對

2.希望輸入資料速度減慢，不然要一直暫停影片來仔細看 output

3.希望還是可以稍微透過某些方式傳達每條自訂測資的涵義，尤其是地圖長什麼樣子。

改進建議：

1.開門一次開一扇門 2.顯示原地圖樣貌

3.可把要輸入的 Input 放在旁邊對照

表 9：學生專案互評成果 1

(二) 組別成果二

自評

組員：B10732011 B10732025

請簡述你在執行專案過程中遇到的問題：

1. 類別交互引用導致編譯錯誤

◼ 解決方法：前置宣告，或是參數設成 pointer。

2. 類別的成員變數在 copy constructor 、constructor、destructor 容易漏東漏西

◼ 解決方法：每新增一個 data member 都去更新這些函式 3. 讓門打開

◼ 解決方法：確認開門條件：回合結束(RoundEnd)場上怪物死亡（MonsterInRank.empty()）

角色站在門上（charaterOnDoor）

4. 偵測門尤其很多扇門在同個關卡跟門有直的橫的

◼ 解決方法：每次在開門事件時都搜尋輸出的地圖（mapTemp）的門的位置，跟觸發開門事

件角色所在的位置，讓那些門變成地板，再重新搜尋可見範圍更新輸出的地圖

（mapTemp）

5. 判斷視野

◼ 解決方法：線性插值法

(27)

6. Coding Style 不同

◼ 解決方法：我們統一大括號在下面、變數名稱要令之前先讓組員知道，或註解

7. 因為是一個人負責地圖主程式跟一個人負責角色怪物，所以要馬上理解對方的思維並不容易

◼ 解決方法：多互相偵錯幾次就很熟悉了。角色怪物那些都需要等程式完成後才能偵錯。

8. 程式碼整合的困難

◼ 解決方法：參考第十八組的 VS LiveShare 方法，以及使用 gitHub。

9. 小組討論效率的困難

◼ 解決方法：訂定每周進度。

10. 題目文意理解困難

◼ 解決方法：詢問同學跟助教以及看測資比對。

11. 怪獸依種類抽卡

◼ 解決方法：紀錄已抽牌的怪獸種類，當輪到下一個怪獸抽牌時，先比對此種類是否已抽過

牌，若已抽過就複製那張卡牌的 index（我們在怪獸的 class 中有一個 data member 紀錄當回手牌 index），沒抽過就呼叫抽牌的 function。

12. 程式架構角色/怪獸動作的 function 不知道要放哪個類別

◼ 解決方法：原本把這些 function 放在卡牌中的 Action 類別中，後來發現這些 function 要牽涉到許多其他的物件（特別是 attack），會需要大量傳入，因此改為架構在遊戲那層

（Gloomhaven），就可直接使用當層的 private data

13. 每個新關卡開啟時裡面的怪獸卡牌狀態要繼承前面關卡同一種類怪獸的狀態

◼ 解決方法：在每次紀錄使用手牌時，紀錄在 MonsterInGame（整個遊戲的怪獸陣列），而

不是 MonsterInRank（當回合可見範圍內的怪獸）

小組分工：

B10732011：主程式、角色怪獸的動作跟流程、偵錯、Demo 影片 B10732025：主程式、地圖視野判斷流程、偵錯、Demo 影片 討論紀錄(紀錄進度)：

(28)

小組互評第一組

組員：B10815023 B10815001 優點：

1. 角色繪圖很可愛，還有動畫 2. 右邊有輸出方便比對

3. 可以用點選也能用打字輸入 缺點：

1. 角色卡牌上半部指令太多就會超出上半部 2. 長休沒有標敏捷值 99

改進建議：

1. 卡片設大張一點 2. 長休標敏捷值

小組互評第二組

組員：B10815027 B10815029 優點：

1. GUI 介面簡潔

2. 選位子的方式非常直覺 3. 卡牌一目瞭然

4. 不用 check 就能看見棄牌跟手牌 缺點：

1. 顏色不清楚

2. 不知道重玩要怎麼重玩 3. 敏捷值會被過多指令遮到 4. 角色可攻擊的怪獸標示不清楚 5. 角色選擇位置起始點未標示 改進建議：

1. 希望能選擇更清晰的顏色，或是改主題（可能可以開發黑夜模式之類的）

2. 卡片能做大張一點，能塞的指令比較多

3. 角色可攻擊的怪獸標示可以更清楚一點，用紅色之類的框住

小組互評第三組

組員：B10830025 B10815035 優點：

1. 介面清晰

2. 選卡牌上下半部很方便

3. 隨時可以看到狀態（shield 那些 缺點：

1. 角色在地圖顯示不清楚 改進建議：

1. Charater win 可以更盛大一些

2. 角色顯示在地圖可以像怪獸一樣用比較鮮明的顏色

表 10：學生專案互評成果 2