不用到處找了，Coding Dojo全攻略奉上
這是一份遲到的小結，去年底組織完Global Code Retreat後，有些新的感受想要分享。結果一路拖延下來，又多了兩次道場活動的收穫。分別是3月份與亞光一起組織的上海敏捷社區道場，和4月底哈羅單車的內部活動。再次印證了當初的想法。
Coding Dojo
最初組織Coding Dojo的想法
一開始我是在公司內部組織的。主要原因是那時候剛剛通過個人練習，在掌握TDD上有所突破。因此非常興奮，想要通過一起練習的方式把我學到的東西傳達給其他人。
基於這個出發點，活動的形式大概是這樣的：
最初內部Dojo的次序
1. 首先進行了一次內部分享，來講解TDD相關的概念，和具體的做法。
2. 爲了讓參與者有直觀的感受，第二次活動是展示形式的。由我演示用TDD一步步完成一個題目。
3. 後面幾次的活動是用MOB形式，一臺連接投影儀的電腦，大家輪流上來寫幾分鐘。旁邊的人一起討論分析。這樣既可以保證整個過程採用了TDD的方式，又給了每個體驗思考的機會。
4. 在大家對TDD都比較熟悉之後，嘗試了結對分組形式，每兩人一組用一臺電腦，同時寫一道題目。然後留一段時間輪流review代碼。
MOB Programming
面臨的挑戰
看起來是費了一些心思逐步推進吧？活動的實際效果也確實不錯。不過，讓更多人掌握TDD這個目標，卻沒有達到預期效果。
那麼面臨的挑戰是什麼呢？
1. 首先TDD是需要付諸實踐的技能，所以單純的宣講作用是不大的。只講紅，綠，重構循環的話，幾句話就說完了。講得更深的話，沒有實踐也很難體會到。
2. 現場演示呢，實話說壓力還是很大的。衆目睽睽之下腦子很容易短路。爲了效果和麪子不免要做充分練習，但是這樣又有一些副作用。
◆ 太熟練了容易講得太快，聽衆跟不上。
◆ 太熟練也會讓人覺得只是這道題目的這種解法練習的次數多，所以才這麼遛。對於方法本身還是持懷疑態度。
3. 然後是輪流MOB的形式。每對輪換上來的人面臨的心理壓力和單獨演示是一樣的，還要理解前面一組的思路。所以往往有手忙腳亂，焦頭爛額的情況。此外各組也可能思路有差異，無法有步驟的分解解決問題。這時
◆ 如果努力引導，把思路帶回引導者自認爲「正確」的路上。一來影響了每個人的參與度，也會讓人覺得是不是僅僅因爲你做過一遍知道答案了而已。二來，也不一定就能引導回來不是。
◆ 自由探索的話，一般來說由於思路反覆和適應新方法的過程。往往在限定時間內進度是很有限的。雖然對於我來說這是意料中的情況，但是是否會打擊初學者的信心就不得而知了。
4. 最後結對同時進行，期待是分別練習前面的收穫。不過由於上面提到的一些困難，往往實際上手進行時發現還有些點沒有掌握，不免卡在某一步。由於分組的方式，難以充分討論每組的詳細過程和困惑。
所以一段時間的操練之後，發現大家對活動本身是比較滿意的，但是卻遠未達到學會TDD的目標。
Global Code Retreat
意料之外的收穫
由於工作調整等原因，去年相當一段時間沒有再組織道場活動，直到最近這三次。
這次由於對於對後續活動難以有很多規劃，是抱着大家一起開心開心，感受一種不太常有的編碼體驗的態度進行的。在沒有預設目標的情況下，反倒看到了代碼道場活動的其它方面，以及可能的引入TDD的路徑。
收穫一自己最關注的，未必是參與者感受最深的
就像前面提到的，Coding Dojo活動雖說是一般化的編程操練，但是一開始就與學習推廣極限編程技能緊密相關，我也一直把學習TDD作爲最核心的目標。然而，一位參與者的反饋卻讓我頗有感觸：
頭一次在掐表限時的環境下寫代碼，感覺非常新鮮。
聽到這個感受時，我突然意識到，由於自己參與過多次道場操練，反倒已經看不到第一次參與者會注意的事情了。
◆ 比如限時，平時除了面試，幾乎是不會遇到的。限時卻又不要求完成就連面試也不會碰到。
◆ 比如結對，平時也只會有不常規的查錯攻堅時才能體驗。
◆ 比如代碼review，雖然大部分公司流程裏都會要求，不過現實中往往被進度壓力追的無暇顧及，匆匆點過。像道場活動那樣爭先恐後的要求上臺被review更是少而又少了。
◆ 比如重構，也是大家都提倡的。但是很少有機會說幹就幹，一羣人注視着改善一段代碼。
◆ 又比如單元測試，後面詳細展開。
收穫二單元測試是很好的切入點
通常討論起來TDD，不論是支持還是反對的，往往並沒有把概念理的很清楚。有時候他在說，我們做TDD，往往實際說的是我們寫自動化測試。
就我的觀察，對於測試的接受程度，可以分爲幾級。
1. 一切測試都是無用的，只有我的智慧和理性纔是程序正確性的唯一保證。
這樣的大神從來沒見過。
2. 端到端測試有用，單元測試無用。
往往潛臺詞是這種測試需要大量的精力。應該由專門的測試人員負責。
3. 單元測試是「正確」的事，但是對自己無用。
後半句一般不會實際說出來，從實際中可以表現出來。比如說起來應該寫單元測試卻從來不寫。爲了應付覆蓋率指標寫等等……
4. 單元測試可以讓我開發的更有效率。
達到這一步的程序員會很樂於自己去寫單元測試。就算還沒有掌握TDD，也只有一步之遙了。
從活動中觀察到的，大部分人都處於第三級的情況，也就是說至少理論上認爲單元測試是有必要的，但是另一方面，很少有人實際在寫。
Unit Test
這幾次活動沒有特意強調TDD或者寫代碼的方式，只是倡導性的希望至少寫一個測試。實際情況是這樣的：
◆ 很多組都可以在限時內基本完成。整體速度高於強調按照TDD流程的操練活動。
◆ 有部分組會寫測試。而不寫的組往往是限於單純的技術問題。比如不知道怎麼引入測試框架，或者因爲從來沒寫過，也不想在有限的時間裏再去研究測試寫法。
◆ 有些組沒寫測試，但是採用了其它方法對代碼做了驗證。比如main方法驗證，打印結果值，做個簡單UI進行手工驗證等。
◆ 在每輪代碼review時，很自然的會反映出測試的作用。比如，
你怎麼知道自己完全實現了題目要求？
如果是xxx的情況輸出會是什麼？
咦？我明明調試的時候測過這種情況呀……
◆ code retreat活動中，同一道題目會反覆寫幾輪。按照規則每輪都要刪除代碼從頭開始。自然而然的就會有小組提出能否保留測試只刪除實現代碼。也就是說只要開始寫單元測試很快就會認識到它的價值，並希望再次利用。
◆ 在重複多輪的活動中，會有越來越多的小組開始寫測試，而且只要開始寫，後面的輪次中都會保持或擴充測試集。沒有人在嘗試後又放棄了這種方式。
可見代碼道場是個很好的機會讓更多人體驗到了單元測試對開發者的助益。也許要在日常工作中大規模使用，還需要克服種種困難比如良好的測試代碼風格，依賴隔離等。但是隻要開發者自己覺得這件事是值得做的，相信這些都不是真正的問題。
Coding Dojo
收穫三改變遠比想象中簡單
Code retreat 活動中同一道題目會操練好幾輪，每輪有不同的挑戰。其中一輪是完全不許使用鼠標。
大部分人的第一反應是「這怎麼可能」——當然這不是真的極端困難的事，我也相信有人能做到，但我不是那種花那麼多精力記滿腦子快捷鍵鍵盤敲得飛起……
然而實際挑戰開始後，有趣的事情發生了。
開始會有人完全無法工作了，或者不得不申請幾次豁免，暫且移動一下鼠標看看需要的快捷鍵。
十分鐘之後，沒有一組還在研究鼠標鍵盤，全都進入到了代碼邏輯的處理中。
這輪挑戰結束，已經不再強制後，後面輪次大部分人會繼續使用剛剛熟悉的快捷鍵。
也就是說僅僅十分鐘，這件事就從「怎麼可能」變成「自然而然」了。出乎我自己的意料。
仔細想來，其實在組織代碼道場的活動中，我收穫過很多這樣的出乎意料。
◆ 擔心氣氛，因爲你懂的，程序員很「悶」。
然而實際中我從未碰到過冷場的情況，相反往往嗨得停不下來。開始我歸因爲我們公司的氣氛融洽，後來歸於週末能來參加社區活動人的主動性。最後我發現，其實程序員本來就沒那麼悶嘛，特別是有個合適的問題的時候。
◆ 擔心結對編程的接受度。
活動中大部分人都幾乎是瞬間接受這個設定的。無論實際中這種配置多麼少見。
◆ 一些實際工作中遇到過的棘手問題。
比如固執己見，過於尖銳的評判等等。事實上從未發生過……
最終我發現，在一個規則明確，目標可控，安全的環境中，大部分人都會更樂於作出嘗試，更容易作出改變。
原文發佈時間爲：2018-05-3
本文作者：武可