這是一份遲到的小結，去年底組織完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活動中，同一道題目會反複寫幾輪。按照規則每輪都要删除代碼從頭開始。自然而然的就會有小組提出能否保留測試隻删除實作代碼。也就是說隻要開始寫單元測試很快就會認識到它的價值，并希望再次利用。
◆ 在重複多輪的活動中，會有越來越多的小組開始寫測試，而且隻要開始寫，後面的輪次中都會保持或擴充測試集。沒有人在嘗試後又放棄了這種方式。
可見代碼道場是個很好的機會讓更多人體驗到了單元測試對開發者的助益。也許要在日常工作中大規模使用，還需要克服種種困難比如良好的測試代碼風格，依賴隔離等。但是隻要開發者自己覺得這件事是值得做的，相信這些都不是真正的問題。
Code retreat 活動中同一道題目會操練好幾輪，每輪有不同的挑戰。其中一輪是完全不許使用滑鼠。
大部分人的第一反應是“這怎麼可能”——當然這不是真的極端困難的事，我也相信有人能做到，但我不是那種花那麼多精力記滿腦子快捷鍵鍵盤敲得飛起……
然而實際挑戰開始後，有趣的事情發生了。
開始會有人完全無法工作了，或者不得不申請幾次豁免，暫且移動一下滑鼠看看需要的快捷鍵。
十分鐘之後，沒有一組還在研究滑鼠鍵盤，全都進入到了代碼邏輯的進行中。
這輪挑戰結束，已經不再強制後，後面輪次大部分人會繼續使用剛剛熟悉的快捷鍵。
也就是說僅僅十分鐘，這件事就從“怎麼可能”變成“自然而然”了。出乎我自己的意料。
仔細想來，其實在組織代碼道場的活動中，我收獲過很多這樣的出乎意料。
◆ 擔心氣氛，因為你懂的，程式員很“悶”。
然而實際中我從未碰到過冷場的情況，相反往往嗨得停不下來。開始我歸因為我們公司的氣氛融洽，後來歸于周末能來參加社群活動人的主動性。最後我發現，其實程式員本來就沒那麼悶嘛，特别是有個合适的問題的時候。
◆ 擔心結對程式設計的接受度。
活動中大部分人都幾乎是瞬間接受這個設定的。無論實際中這種配置多麼少見。
◆ 一些實際工作中遇到過的棘手問題。
比如固執己見，過于尖銳的評判等等。事實上從未發生過……
最終我發現，在一個規則明确，目标可控，安全的環境中，大部分人都會更樂于作出嘗試，更容易作出改變。
原文釋出時間為：2018-05-3
本文作者：武可
本文來自雲栖社群合作夥伴“
中生代技術”，了解相關資訊可以關注“
”。