緣起
在三個月前，我在 ptt 上 po 文（[分享] 免費程式教學(前端)），說我願意提供一系列的免費程式前端教學。只要是有網頁基礎的都能夠報名，歡迎大家寫信給我，並且附上幾個提問的回答，最後我會挑 5~10 個人進行培訓。
上面所指的提問如下：
- 自我介紹（例如說背景、怎麼學程式的、程式能力到哪）
- 學程式多久了，當初為什麼會想學程式
- 現在在工作嗎？是的話工作內容大概是什麼？
- 最近碰到過的一個最難的程式問題
- 希望我可以給予哪方面的協助
那篇文章是 3/2 發出的，報名截止日期到 3/11，而 3/15 以前會寄信給被我錄取的人
先來講講當初為什麼會想要開這個免費程式教學吧！其實原文裡面也有寫了，我再講得更清楚一點
在這之前，其實我就曾經辦過類似的活動了，雖然也是程式教學，但其實來找我的都是毫無經驗的初學者，我能給的都是一些比較大方向的建議，例如說跟他們介紹什麼是前端、什麼是後端，介紹幾種程式語言，並且推薦給他們適合初學者的。
上一次教學大概接觸了十幾個人，可是卻幾乎沒有一個「真正碰到寫程式」，都僅止於「想學程式但又還沒開始」的階段
可是這不是我想要的，我想要的是實際讓學生們動手寫程式，並且驗證看看「我的方法」是不是真的有效，至於這個方法是什麼，我們稍後會提到。因此，我這次的教學才會把學生限定在「有前端程式基礎」，那代表我可以往更深的地方去教。
爆炸的信箱
文章 po 出之後在 ptt 上的迴響還行，大約是 30 幾個推，以軟體工作版這種比較小的板來說算多了。但事實上，報名的人數遠出乎我的意料。
到報名截止日期為止，我一共收到了 42 封信。
是我原本想收的人數的四到八倍左右（原本我只想收 5~10 個），而且有很多人都寫得很不錯。其實，從這些信件就可以看出每一個人的個性了，有些人比較懶，隨便寫個三四行就寄過來；有些人很認真，甚至還提供履歷或者是有精心排版。
那怎麼辦呢？我要怎麼從裡面篩出我要的人？
算了，太麻煩了，乾脆就全收吧！
沒錯，我真的是這麼想的。於是，拒絕掉真的不適合的 4 個人以後，最後錄取的有 38 人。
下面附上我當初寄給所有人的錄取通知：
Hi,
收到這封信，就代表你已經錄取了。
但其實說「錄取」我自己也覺得有點怪啦，因為並不是什麼正式的活動，辦這個程式教學的初衷就純粹是我希望四五年前我剛接觸前後端網頁程式的時候，也有人能夠這樣帶著我，給我一些建議。
但那個人始終沒有出現，於是在四五年過後，我決定自己跳下來做那個人。
在寫程式的路上一樣受到了很多前輩們的幫助，Google 跟 Stackoverflow 也惠我良多，就是因為受過太多人的幫助，才讓我一直覺得「回饋」是一件我必須要做的事情。
前言差不多就到這邊了，這封信是統一回給大家的，接著會介紹一下之後這個活動的走向。
這次的報名比我想像中的踴躍，大約有 40 位朋友們都對這個活動有興趣，雖然當初文章寫說只收 5~10 位，但仔細考量過後，發現其實每個人的需求都不太一樣，基本上可以把需求分為兩類。
第一類是想要練習前端基礎，希望我能夠出作業或是給一些指導的；第二類則是已經有前端的程式能力，希望能跟我聊聊工作上相關的事情，例如說我是怎麼到新加坡工作，要達到什麼樣的程度等等的。
針對這兩類的需求，會分為兩種方式來進行。
第一類的話大約每週或是每兩週會出一次作業（或者是之後有可能改成作業全部都先出好，大家自己可以有自己的進度），然後固定時間我會統一講解這次作業裡面你應該可以學習到的知識點，再加上我自己的一些補充。
第二類的話基本上能力沒什麼問題，我也沒有甚麼可以教的，所以主要就是跟你們約個時間，然後我們來聊聊天，就當作是參加什麼技術分享會跟隔壁的人聊聊天就好。不用有什麼太大的壓力，聊一聊也可能發現其實你的技術能力比我強。
大家都已經有寄信對我做個簡單的自我介紹了，現在換我來做個簡單的自我介紹。
我叫胡立，現在在新加坡擔任前端工程師，來這邊大約五個月左右而已。
學程式是從升國中的時候開始，一路上基本都自學，小時候寫 VB，長大之後跑去玩程式競賽寫 C/C++，之後對手機程式有興趣跑去寫 Java, Android，大學時終於踏上網頁之路學習 PHP 跟前端網頁。實習時候發覺自己對前端比較有興趣，就開始比較專攻前端以及 Node.js 後端開發
更詳細的資料你可以參考我的 Linkedin：https://www.linkedin.com/in/hulii，之後的交流大家也不用太嚴肅，就叫我 huli 或是胡立就好，太嚴肅的話我也會覺得怪怪的XDD
有關於這個教學活動，還有以下幾點要跟大家說明：
你可以「隨時退出」，因為你有可能把我想的太強，但實際教學時卻發現我好像沒那麼強，就跟你的期待有落差。如果碰到這種情況，覺得我沒有辦法給你什麼幫助的話，那你可以直接來跟我說或是怕尷尬的話隨便想個理由也可以。這沒什麼的，不用有什麼壓力。
一定要給我回饋。無論我教得好或是壞，都麻煩大家給我一點回饋，我之後會開一個匿名的 Google 表單讓大家填寫，還麻煩大家在教學結束之後給一下 feedback。
學習還是要靠自己。儘管我可能會給你一些方向，給你一些建議，但畢竟師父領進門，修行在個人，你們之後會變得怎麼樣，就看你們自己了。
就差不多是這樣了，在這邊有兩件事情要請大家幫忙，才能讓我們順利開始
- 加入 Slack（沒用過的可以自己去 Google 一下教學）
- 在 Google 表單填寫基本資料（這超級重要，一定要填）
以後 Slack 就是我跟大家溝通的管道了，所以麻煩 Slack 的通知要開一下，如果我在 Slack 上面一直沒回你的話，可以多找我幾次或是一樣寫 email 給我。
現在離四月大概還有三週的時間，我會在這段期間內盡量找「每一個人」聊一聊，如果你是第二類，就是想跟我聊一聊的話，那我們的緣分(?)大概就是聊完就結束了，因為之後我也沒有什麼可以幫的了XD
如果是第一類需要教學的，就大概根據你之前的那篇自我介紹簡單閒聊一下，也會聊到目前對這個教學活動的期待以及更具體地、希望我能夠給予的幫助，教學部份的話預計是從四月初開始，我會再找時間統一跟大家 update 一下最新的狀況。
下面附上初步想出來的第一類的教學大綱，如果你覺得下面這些你都會了，那其實沒什麼必要聽我教學，因為我能教的就這些了XD
我擅長的比較偏 js 而不是 css，所以期待能學到什麼厲害 css 技巧的朋友們可能會失望了，我自己也不太會切版，RWD 也會苦惱很久，在 css 這部分比較不能提供什麼協助。
- 練習實作 Twitch 遊戲畫面排版（知識點：基本 html, css）
- 讓畫面變得更動態（知識點：css transition）
- 改用 Less, Sass 或是 Stylus（知識點：css 預處理器的使用）
- 串接 Twitch API 拿取資料（知識點：看懂 API 文件、API 串接、Ajax、CORS）
- 優化：加上 infinite scroll 與 placeholder（知識點：infinite scroll, placeholder）
- 改用 vanilla js 實作（知識點：vanilla js）
- 加上多國語言（知識點：i18n, library）
- 把 CSS, JS 全部都 inline 到 html（知識點：gulp、為什麼需要 gulp）
- 我們為什麼需要用 Webpack？（知識點：webpack）
- 改用 React.js（知識點：React.js）
（視情況增加 Redux, React-router 等等的教學，因為教學內容可能會變，就沒有先規劃那麼多）
最後幫大家條列式總結一下現在狀況：
- 加入 Slack，填寫 Google 表單
- 跟每個人都會先聊聊，但你可以選擇聊完後你要不要參加我上面那些程式課程（就是選第一類的意思）
- 等待我主動跟你聯絡敲時間在線上聊個天
- 聊完以後等待通知開課
感謝大家的配合，
Huli
一開始的兩週我大概跟 20 個同學一對一聊過了，大約七成用語音三成用文字，就聊一聊彼此的狀況、從什麼時候開始學程式的、程式程度大概到哪邊以及對課程大綱的看法。
其實這個課程最重要的就是課程大綱了，我們馬上來仔細看一下！
課程大綱背後的涵義
會擬出這個課程大綱，主要有兩個因素，第一個是因為裡面教的那些東西，剛好都跟我近期的工作內容有相關，因此教起來我會比較得心應手，畢竟自己就在碰這些東西。
第二個原因是因為我在工作上接觸到這些東西的時候，我原本也是什麼都不懂，不知道 webpack 在幹嘛、不知道 gulp 在幹嘛、不知道 infinite scroll 到底怎麼做。可是當我花一段時間理解之後，我知道為什麼當初的我覺得這麼難了。
因為我不知道是用在哪裡，我不知道是幹嘛的，或是說，我不知道「我為什麼要用」，我在網路上找了一大堆教學，每一篇都在跟我說「怎麼用」，卻很少有資料能告訴我：「為什麼要用」、「如果不用會怎樣」
在幾次教學經驗的累積過後，我找到一個我認為比較有效的教學方式，原則就是：
要先痛到，才會得到
這是什麼意思呢？
我有一陣子很喜歡看大公司的一些架構文章，裡面寫說他們怎麼把機器架構調整成適合規模化，講說他們碰到了什麼問題，用什麼解法解決了超大資料量所帶來的 Bug。
我一開始覺得很有收穫：「哇，這些感覺好厲害啊，學到很多」。可是過一陣子之後，才發現自己什麼都沒學到。那些東西過一週之後我就全部忘掉了，好像文章根本沒看過一樣。
後來我忘記在哪邊看到一篇文章，裡面有一段傳達的意思我記得特別深刻（如果有人也看過同樣一篇，麻煩在底下留言，小弟感激不盡），文章裡面寫說，那些都是大公司的高手們痛苦過、經歷過所淬煉出來的「精華」，你怎麼可能期望你看了十分鐘，就能夠擁有他們十年的功力？
「痛過」，是一件很重要的事。
與其直接教他們寫 SCSS，不如先讓他們寫 CSS，然後一直叫他們改顏色，叫他們改東改西。這時候他們就只能一直用文字編輯器尋找->取代，不斷重複這個循環。等到你確認他們真的痛了，再教他們 SCSS。
這時他們會有種「重獲新生」的感覺，「靠！原來還有這種東西喔，這樣就不用改這麼辛苦了，用變數就可以了」，這樣子的學習方式我認為會比起直接教有效許多。
在教他們一樣東西之前，我一定會想辦法讓他們知道說：「為什麼我需要這個」，我認為當這個問題搞懂也同意之後，才會更有動力去學習，也才能知道自己到底在學什麼，學了之後可以幹嘛。
還有另外一件事，那就是比起每一個不同的小作業，比較好的做法是「一個逐漸加強的作業」，這樣在做作業的時候，學生可以不斷地看見自己的進步，不斷地看見專案的成長，而且最後會做成一個完整的，而不是一堆零碎的、破碎的小專案。
因此，我就以這幾個概念規劃出了這些課程大綱，後來有稍作調整：
- 基本 HTML/CSS 練習：以 Twitch 為例
- 讓畫面變得更動態：神奇的 CSS transition
- 寫 CSS 必備神器：CSS 預處理器
- 從假資料到真資料：Ajax 與 API 串接
- 讓網頁變得更完整：加上 placeholder 與 infinite scroll
- 返璞歸真：vanilla js
- 走向國際：i18n
- 當我們包在一起：Webpack
- 節省 Request 的極致：一為全，全為一
- 改掉你的壞習慣：ESLint 與 standard
第十週原本是 React.js，我後來拿掉了，原因有兩個。第一個是我認為 React 放在這邊不適合，還沒到教的時機點，還不夠「痛」，而且跟前面的也沒有什麼關聯。第二個是我改作業發現很多人的 coding style 不好，所以第十週放這個，前面九週作業寫得越醜的要花越多時間改，讓他們「痛」一下。
我必須先承認，上面這個規劃並沒有很好地使用到「痛到才會得到」這個教學原則，這個是我還可以再做得更好的部分，進步空間還很大很大。
而由一個小作業逐漸加強我覺得我算是滿好的掌握到了，一開始先讓他們刻一個靜態版面，再來把 CSS 換成 SCSS，然後把假資料換成真的資料，串 API。接著加上佔位圖以及無限滾動，讓頻道可以一直滾動加載。
第六週的作業目的是拋棄 jQuery，節省檔案大小，也讓他們知道原來不靠 jQuery 還是可以寫 JavaScript 的。第七週把中文換成中英雙語，可以支援兩個語言，第八週改用 webpack 實作模組化，第九週用 gulp 讓他們知道原來很多事情都可以自動化，最後一週修正自己的 coding style。
這樣子逐漸優化的過程，他們在做下一個作業的時候就可以直接接續上一個，把一個專案變得越來越完整。
解決問題
如同我一再強調的，寫程式不是重點，重點在「解決問題」，幾乎所有事情的重點都在這個。
解決問題又可以分成以下幾點來思考：
- 你要解決什麼問題？
- 你用什麼方法解決？
- 這個方法有什麼優缺點？
我很喜歡一個詞叫做 trade-off，中文可以翻作：權衡、取捨。
尤其是在寫程式的領域中，你做什麼事其實都是一種 trade-off，最常見的例子就是時間換空間或空間換時間，沒有那麼好康的事情讓你又有空間又有時間。好啦，其實有，但那都是用錢換來的。
我在每一週的作業說明裡面，都會提到說我們這週碰到了什麼問題。那解法呢？解法當然就是那一週要教大家的東西囉。以下我們把每一週的課程再剖開來看，自問自答上面那三個問題（解決什麼問題、如何解決、優缺點）：
基本 HTML/CSS 練習：以 Twitch 為例
- 解決什麼問題：我想有一個頁面可以看 Twitch 頻道
- 解決方法：自己寫網頁
- 優點可以客製化，缺點是花時間
讓畫面變得更動態：神奇的 CSS transition
- 解決什麼問題：想要加上效果讓頁面更精緻
- 解決方法：用 css transition 這個屬性來做漸變效果
- 優點是有了漸變效果，缺點是可能有效能問題
寫 CSS 必備神器：CSS 預處理器
- 解決什麼問題：寫 css 太麻煩，想要有像程式那樣的變數可以使用
- 解決方法：用 css 預處理器
- 優點是方便維護，缺點是需要多一步 compile
（像這個時候，就必須衡量優缺點，在這邊顯然優點大過於缺點，因此我們有一個「好理由」採用這個解法）
從假資料到真資料：Ajax 與 API 串接
- 解決什麼問題：現在的資料都是寫好的，我想要有真實的資料
- 解決方法：串接 Twitch API
- 優點是資料變真的了，缺點是看到畫面的速度變慢
（如果你要解決這個問題，必定要串接 API，因此這邊的缺點其實可以忽略）
讓網頁變得更完整：加上 placeholder 與 infinite scroll
- 解決什麼問題：一次載入 100 個頻道太慢，並且在載入時會跑版
- 解決方法：採用捲動到底才載入新頻道的方式，並且加入佔位圖防止跑版
- 優點是使用者體驗變好、首次加載變快，缺點是 request 數量變多了
返璞歸真：vanilla js
- 解決什麼問題：jQuery 檔案大小太大，想減少 request 大小
- 解決方法：把 jQuery 拿掉，不依賴任何 Library
- 優點是檔案大小減少，缺點是程式碼複雜度提高，必須自己處理跨瀏覽器問題
走向國際：i18n
- 解決什麼問題：想要新增一種語言
- 解決方法：把語言放在語言檔裡，引入之後靠 window 這個全域變數傳遞
- 優點是可以有多個語言，缺點是污染全域變數
當我們包在一起：Webpack
- 解決什麼問題：解決上一次作業的全域變數污染，以及想要使用 require 的這種語法
- 解決方法：導入 webpack
- 優點是模組化開發，缺點是需要多一層打包，以及檔案大小增加
節省 Request 的極致：一為全，全為一
- 解決什麼問題：Request 太多
- 解決方法：把 JavaScript 跟 css 全部 inline 到 html
- 優點是減少 Request，缺點是開啟頁面的時間變慢
改掉你的壞習慣：ESLint 與 standard
- 解決什麼問題：寫程式碼的習慣不好，不利於團隊開發
- 解決方法：導入語法檢查工具
- 優點是統一程式碼規範，缺點是…好像沒什麼缺點
比起「webpack 是一個打包工具」這種介紹，你讓初學者們知道 webpack 到底是幹嘛的、是要解決什麼問題、要怎麼解決會有用的多。再次強調，問為什麼很重要，知道為什麼也很重要。知道背後的原因，你就可以決定你要不要用這一套解法。
你用一個東西，背後必須要有一個「好理由」。
A：我們改用 TypeScript 吧
B：為什麼？
A：因為潮啊！
如果「潮」這個理由不夠有說服力的話而 A 又提不出其他更好的理由，那就沒有必要改用 TypeScript。
之前有一篇很紅的文章，叫做：在 2016 年學 JavaScript 是一種什麼樣的體驗，我覺得有一個很可惜的點，那就是有些人看完之後的心得都只有：「唉，對啊！前端現在也太複雜了吧！」
但我覺得這篇文章你應該去思考的是：「裡面那些工具是不是真的需要用到？那些工具想解決的問題，到底是不是我碰到的問題？」，這才是這篇文章的重點。
舉例來說，裡面有一段這樣寫：
可別用 jQuery！現在哪還有人用 jQuery。現在是 2016 年了，你絕對應該用 React。
這個理由跟上面的一樣薄弱，一個字：潮！
當然，他也可能是其他意思，也有可能是想表達說 React 是近年趨勢，jQuery 可能會慢慢被淘汰並且不再維護，以後就有維護性的問題。這時候你就可以考慮說：這樣的情形是不是有可能發生？如果真的發生的話，會有怎樣的影響？用 React 帶來的複雜性跟 jQuery 的可維護性哪一個損害較小？
總之呢，重點應該是「你要解決什麼問題，這問題用哪些工具來輔助最適合」，而不是一味的覺得前端怎麼那麼複雜那麼多東西。
是啊，本來就一堆東西啊，可是裡面可能有八成你根本用不到啊！
如果你寫一個一頁式的行銷 landing page 還硬要用 React + Redux + Rx + Webpack 的話，那我也是醉了。
課程進行方式
這堂課程的進行方式是這樣的，如上所述，總共十個作業，每一個作業一週，必須「先做作業」，但做不出來也沒關係。每個禮拜二我會直播講解上一週作業並且實際示範如果是我的話，我會怎麼做。
會這樣規劃是因為「自學」無論在哪個領域，都是一個重要的技能。我想先讓同學們對於我要教的內容有概念，甚至是把作業做出來以後，我再重新講解一遍。我覺得唯有這樣，才能讓同學們對我教的東西更熟悉。
這就呼應到我上面提過的「要先痛到，才會得到」，事後有很多同學都反應他們課前預習時覺得有些東西好難，怎麼看都看不懂。可是一看完我的直播教學，就有種茅塞頓開的感覺：「哇！原來這麼簡單」。
如果相反過來呢？假如是我先上課，他們就只會覺得：「喔，是這樣寫」，接著寫作業的時候就直接抄我的解法就好了。他們學到了什麼？學到模仿我的程式碼，然後過一個禮拜完全忘記這個解法。為什麼？因為他們沒有痛過，所以沒有去思考。
來，再次強調，你寫程式的時候要思考！要思考！要思考！只有思考過，深思熟慮過的東西才是你的，你才記得住。
課程成效
講完了課程大綱的設計理念，以及我自己在這堂課最想要傳達的核心思想之後，該來談一下這堂課程的成效了。
前面有說到一共 38 人收到錄取信，到後來只有 36 人填寫基本資料，兩個人就這樣消失了。
而這 36 人之中，只有 26 人有完成第一次作業，意思是說，有 10 個人連作業都沒做，28% 的人就這樣不見了。因此之後的數據我會把參與這次課程的人數調降為 26 人。
能夠撐完十次作業的，只有 8 個人而已，大約是 30%。
下圖是每一次作業完成的人數
可以看到掉得最多的一次是 hw2 -> hw3，寫 CSS 必備神器：CSS 預處理器，我也不知道為什麼這一週會掉這麼多人。
課程結束之後的問卷回饋，作業沒有做完的理由有：時間無法配合、作業難度太高、懶惰、有其他事情、沒興趣。
而問卷中有一題是：「覺得難度最高的作業是哪一個？」，大多數人的回答都是 hw5（讓網頁變得更完整：加上 placeholder 與 infinite scroll）跟 hw6（返璞歸真：vanilla js），因為以前完全沒有寫過類似的東西。
如果以後要改善的話，可以把 hw5 再細切成幾個單元，而不是一次就完成這兩項，hw6 也可以用類似的方法，這樣對學生來說應該就不會一下子難度跳這麼多，而是慢慢變難。
學員回饋
課程結束之後有請大家填了一下回饋的表單，很幸運地，大家感想都滿多的。我原本想要把原文全部貼上來，但這樣篇幅會太多，有點妨礙閱讀，因此我只擷取部份，刪除掉一些重複的內容。
老師在講解或改作業時有什麼優點？
（以下皆為回饋原文，我只修了一些排版而已）
- 講解的部分使用 Youtube 直播可以方便學生彈性安排時間聽課。講解的內容有個很大的優點就是 Huli 會用非常淺顯易懂的例子與概念切入，讓自己有時候花了一兩天寫的作業，聽完講解後覺得「哇靠原來這麼沒有想像那麼難」，而每一堂講解的編排有組織性，也很容易整理筆記。改作業的部分，Huli 會仔細看我有列出的 troubleshooting 並提供有用的建議，也會在做的不錯時給予滿滿的鼓勵，這對新手入門算是很棒的引導。
- 講解的時候講到很多我原本準備好要問的東西，而且講解方式很容易讓人理解，因為有交代原因，所以也很容易讓人接受。就像安排課程一樣，每個章節循序漸進，就會很容易理解以及接受為什麼要用這些東西，以及這些東西的好用之處。
- 雖然我只有交前面幾次作業，不過可以看得出來有用心在看作業。講解方面，我覺得非常好不會突然出現尷尬的時候，也講得很清楚！
- 直播完整程式 live coding 過程，包括用terminal執行指令，讓我這個 terminal 生手不再害怕使用 terminal，也對它越來越熟悉了，是這次程式課後的額外驚喜收穫。講解程式會讓人覺得原來寫程式可以這麼清晰簡單，講解過程看似輕鬆卻有架構。當同學聽不懂時會用很多不同角度切入解釋，像是生活化例子或是各種相關連結以加深同學對程式的觀念和印象！
老師在講解或改作業時有什麼缺點？
- 感覺上沒什麼缺點，如果要說可以更好的地方的話，感覺上 IDE color theme 可以用字與背景對比強一點的，觀賞上能增進使用者體驗。不過整體而言不成大礙。
- 可以的話，可以準備個 txt 檔案把當天要說的重點寫上去順便當標題XD
- 當課程內容如 webpack 和 gulp 是我完全陌生的東西，也沒碰過 node.js 下，聽起來就會覺得講解速度較快，尤其直播課時會說這 webpack 和 gulp 作業算很容易，就會讓初學 node.js 的我有些感到挫折…希望自己能培養對新事物有更快速上手的能力。
- 這倒不算是缺點，只是小建議。如果要在直播時節省時間，可以先在直播前把可能需要用到的網站先放在瀏覽器。不過直接在直播時搜尋的好處是，我們事後要搜尋可以知道你利用什麼關鍵字去搜尋。
課程心得
回饋問卷裡的心得礙於篇幅，貼在這邊不太適合，因此我只貼兩篇寫在自己 Blog 的。
自我檢討
先來說缺點的部分，其實比起優點，我更想聽到的是缺點。因為知道缺點在哪邊才能持續改進嘛，但不知道是這次表現太好還是學生不好意思，缺點的部分回饋的比較少。
身為一個不斷追求進步的老師，就算學生沒講，自己也應該要察覺到一些缺點。
1.改作業有時候馬馬虎虎。
雖然學生說改作業很用心，但其實有時候我一次面對堆積如山的十幾個作業，很多東西都只是快速看過去而已，畢竟老師也是會懶惰的…這是我之後可以再改進的地方
2.課程規劃不夠「痛」
上面我有提到要先痛過才能理解，我覺得作業還可以再切得更細，讓學生更「痛」一點。例如說培養 coding style 的部分，可以先出一個作業規定大家：「變數名稱只能用一個英文單字，例如說 a, e, y 等等，不夠用的話加上數字變成 a0 等等」，做完一次作業之後，隔週再讓大家看自己上週寫的程式，應該會發現看不懂在幹嘛。
這個時候，他們就會知道變數命名的重要性了。
接著談談優點，開頭有提到說這是一場：「三十人的教學實驗」，實驗目標就是驗證我上面講的那些教學理念（要先痛過、要懂目的、要知道為什麼）是否真的能幫助學生學習。
從學生反饋的結果看來，我認為是可以的，這也更加確認了我以後課程的規劃方向。
有關優點的部分，我就直接貼幾個學生的回饋上來吧！從這些回饋裡面就可以發現，我想傳達的，他們都能夠確實接收到。
講解的時候講到很多我原本準備好要問的東西，而且講解方式很容易讓人理解，因為有交代原因，所以也很容易讓人接受。就像安排課程一樣，每個章節循序漸進，就會很容易理解以及接受為什麼要用這些東西，以及這些東西的好用之處。
講解程式會讓人覺得原來寫程式可以這麼清晰簡單，講解過程看似輕鬆卻有架構。當同學聽不懂時會用很多不同角度切入解釋，像是生活化例子或是各種相關連結以加深同學對程式的觀念和印象！
很喜歡老師的教學是讓同學先寫再公布答案，讓同學有機會先嘗試各種自己先想的到或找的到的可能解法，而等到直播課時才公布老師的做法，可以有互相交流切磋的機會，也不會讓同學是腦袋空空去上課。因為都先寫好作業了，在課堂上也更易吸收和整合，也能馬上快速理解哪種情境適合哪種解法，也能一眼發現自己先前卡住的地方在哪，因為都已經卡過了。
在這次程式課也發現寫程式這件事的思考沒有想像中的複雜，可能和老師的教學大綱切的清楚乾淨，以及講解時是以「需求」為出發點。一些新手，像是我，常常在開發過程花了一堆時間，總是在寫連自己也不太懂自己幹嘛或為何而寫的code。寫code時的思考是我在這堂程式課學到的珍貴收穫。
總結
先感謝我的學生們，陪我走過了十週的課程，並且願意在結束之後給予回饋。
我一直覺得，程式教學應該要能有更好的方法，能夠幫助學生更快上手、更快理解。這次的課程讓我驗證了我目前的方向是對的，之後也會一直朝著這方向前進。
如果你對這次課程感興趣，可以前往課程的 Github 頁面觀看課程內容，或是到Youtube直接觀看影片。
也可以直接到我最近才開的線上課程平台：Lidemy 鋰學院註冊課程，完全免費！我把作業內容跟影片都上傳到上面了。（但因為課程已經結束了，所以沒有人會幫你改作業）
我認為這堂課的價值在於「先寫作業，後講解」的教學模式，因此像上面這樣把教學影片公佈出來，我不打算盈利，都是完全免費的資源，開放大家隨意取用，因為這堂課的核心價值已經不見了，所以也沒必要收費。
我希望我的課程在各個環節上都能夠公開透明，因此，若是對學員課後提交的回饋表單有興趣，這邊有學員回饋的完整備份（只有刪除掉一些個人資料）。
最後，感謝大家願意花時間閱讀這篇落落長的文章，若是對我後續的教學實驗或課程有興趣，麻煩請追蹤Lidemy 鋰學院粉絲專頁，後續的消息都會公布在那邊。
感謝。
評論