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