專業主義的秘密 - 練習

先前和朋友聊到，最近同時間看一套日劇 Dinner 和 著名的 The Clean Coder  一書，被其中的專業主義感動到不行。

The Clean Coder  剛看完第六章，章名是我從來沒有跟大家分享過，卻是我奉行已久的關鍵字 - 練習。

我絲毫不想透漏Dinner的劇情，以及Robert C. Martin在The Clean Coder ㄧ書中提到關於練習的描述。這些東西(看Dinner這部片以及The Clean Coder這本書)將是屬於你這個月最頂級的享受，我不忍心剝奪它。但我忍不住要說，Dinner男主角在每天下班後忙到深夜的事情、和Robert C. Martin用了一整章說的故事，說到底，都只有簡簡單單卻始終被大家忽略的一個字，練習。

這年頭，很少程式設計師會進行"練習"了，而且是重複的練習。但你絕對沒有意識到，這件是有多麼的重要...老實說，如果不是因為要上課，我自己大概也沒有機會有這麼深的體會。但是，在這邊我要跟大家分享的，就是這近十年來，我擔任教育訓練人員、作者、或是顧問時，一直奉行不渝的 -- 練習。

練習什麽呢? Robert在書裏面有說，像是kata, wasa之類的(這你要看書才知道，說過了，我不想剝奪你的樂趣)。但我想跟大家說我自己的經驗，那就是『研討會前的練習』。

如果你熟悉我，你就會知道我講話的速度應該不算慢，在研討會上，我盡可能在兼顧清楚的情況下，以最快的速度跟大家分享，同時間，每一場次的研討會，我都要求自己，要盡可能地與學員互動。

我們也都知道，大夥兒希望看到Live Demo，也因此，我的每一場研討會，幾乎都會有Live Demo的部分，拿今年TechDay Taiwan 2013的例子來說，架構設計的場次中，我簡單Demo了應用程式的分層開發、Unity Application Block的例子、Logging Application Block的例子。在WP8的場次中，我介紹了動態磚、Lock Screen、NFC、App Communication，其中都不乏Live Coding。

一場研討會的時間是70分鐘，其實講師們都清楚的知道，只要Live Demo當中，有一個環節不正確或出現意外狀況，幾乎就有可能讓整個Session毀掉，你不可能讓台下的學員看你在上面Debug、Try and Error...再Debug，或重開機...。也因此，Live Demo要盡可能的行雲流水，如果是超過兩三個範例，那麼挑戰就會倍增，如果再加上幾個不確定性因素，例如網路連線狀況(速度慢或斷線)、投影機(螢幕解析度)、緊張(不熟悉的場子)、麥克風(沒有領夾式的麥克風，導致只剩一隻手敲鍵盤)...這些都會大大影響整個Live demo的狀況，也因此，要順利成功的進行Live Demo，關鍵因素只有一個，就是大量的練習。

你要不要猜猜看我在每一場大型研討會前，要Live Demo的內容有做過多少次練習? 我要告訴你，每一個範例、每一個動作，絕對都"完全一樣地"重複練習超過三次以上，如果時間夠，我會練習到五次，其中一次會錄影起來，以備不時之需。

同樣Demo一個範例，例如用WP8建立一個iconic tile，我會在有網路、沒有網路的狀況下各練習一次，接著把螢幕切成只有1024x768的時候，再練習一次(因為投影機大多只支援到這個解析度)。練習時寫的Code完全不變，就是換不同的環境，如果時間允許，我會換一台NB(或開一個虛擬機)，再練一次。

因為多年的經驗，我們清楚的知道，有網路和沒網路很可能Demo效果和路徑(操作步驟)會完全不同，在1024x768或1280x800的解析度下，滑鼠點選螢幕上的某個視窗，位置可能會不同，這會影響Live Demo的路徑、而路徑會影響速度，甚至會影響你的信心。

因為我們清楚的知道，一旦因為解析度不同、或是網路沒有連線，導致正式上場時Live Demo的路徑(操作步驟)和在家裡操作的不同，講師很容易緊張，ㄧ緊張，就會出錯。

所以我得說，你在現場看到ㄧ次順利的Live Demo，其實往往是講師(至少是我)，以完全同樣的步驟在家裡、公司，練習過了三五次之後的結果。先不談準備內容和撰寫範例，光花費在重複練習的時間，已經超過研討會正式上場時間的五倍以上。

但是充分的練習，才能讓我們正式上場的時候不緊張，才能夠在各種環節與情境下，都隨時保持著自信、泰然自若的面對各種可能發生的問題。Live Demo時，打錯一行字，出現ㄧ個Bug，不急，別怕，因為我練習的時候碰到過，不擔心，我知道怎麼解決。

我告訴你我在練習時碰過的幾個極端的例子，包含建立專案的時候不能Build，是因為專案資料夾名名稱+檔案名稱超過Visual Studio的長度限制；用NuGet安裝套件，碰到臨時沒網路忘了要裝那些.dll；開的專案範本不同，套件在.net 4.5才能run，Demo時候卻開到.net 4.0的範本，某些.dll裡面隱含著用了另一個不知名的.dll卻忘了add reference...這種狀況，如果是在台上臨時遇到，我可能直接束手投降，放棄這一段的Demo。但沒有，你幾乎沒看到我們在台上這樣，因為那些問題正式上場時幾乎沒發生過。而沒發生，是因為我知道可能會有這個狀況而先避開了，這些...都是因為事前的練習。

最近這幾年，我習慣把練習的過程順便錄成影片，因為要錄影，所以會有我的旁白，也就是錄影時候的說明，這個說明，事實上又是另一次的練習。我除了在上台前會將Live Demo練習幾次，包含每一張投影片上該講的內容，都會試著整個走過一遍，如此一來就可以知道大概需要多少時間，哪一張投影片需要長一點、哪一張投影片可以稍微帶過即可。而練習時Live Demo的錄影，也可以讓我預先練習現場要跟學員怎麼說明和介紹這段程式碼，因此我幾乎在比較大型的研討會，都會事先把影片錄好的原因，錄影的過程，也是一種練習。

如此一來，準備一場研討會，我大概寫了5-10次的動態磚建立、5-10次的Unity Application Block的範例、5-10次的Logging Application Block的範例5-10次的Lock Screen、5-10次的NFC、5-10次的App Communication...

到最後，一場研討會下來，最熟悉整個開發的流程，收穫最多的，其實就是我自己。上課強迫我非得hands-on，而實際下手去做，才是真正"有效的學習"。
===================
後記：
你可能覺得，我又不是講師不多機會上台介紹技術，那還要練習幹嘛? 其實，只要你是ㄧ個程式設計師(甚至是Sale, Presale)、需要跟客戶、老闆、長官 Demo、需要準備驗收的UAT，需要對內部同仁進行技術分享，你的Demo都應該要事前練習，甚至只是看ㄧ本書之後的心得記錄，寫寫blog...這些都是你可以練習的機會，有機會，就不要放過，前面說過，多練習，實際下手去做，才是真正有效的學習。