[N社筆記] 在公司小規模玩 Coding Dojo

前情提要

在上 91 大的(熱血 Coding Dojo 第一梯次)的課程中，
我一直在思索一件事，為什麼我作不到呢？

我不希望只是上了課之後，「喔喔喔 我好興奮啊…」就結束了，
所以馬上找了一起上課的兩個同事開了個簡單的 Retro
我只有一個問題，
「如果你覺得這堂課有效的話，我們要作什麼 才能帶來改變呢 ?」

開起小型 Dojo

我們簡單的作了一個決定，我們要在公司內部建立一個 Dojo
並且簡單的訂定了三個目標

1. 學習 Pair ，並透過 Pair 彼此學習
2. 學習 TDD ，並透過 TDD 學習重構
3. 學習 Vim，並提昇開發速度

這三個東西都是在課堂上學習到的，幸運得是我們當中有兩位已經會基本的 Vim 指令，
當然也各有各的問題，ex: 不熟悉英打、沒有 Reshaper 、找不到共同的時間等…

總而言之，我們就這樣開始了。

第一個 Kata

第一個 Kata 是很重要的，Coding Dojo 提供我們一些選擇，
Tennis Game 與 Poker Hand 都是很好的題目，
但是新手上路，我們選了一個簡單的 Fizz Buzz 當作練習題目。
Fizz Buzz 的需求分析是很簡單的，

1. 傳入 1 數，可以被 3 整除，回傳 Fizz
2. 傳入 1 數，可以被 5 整除，回傳 Buzz
3. 傳入 1 數，可以被 3 整除，且可以被 5 整除，回傳 FizzBuzz
4. 不符合上述條件回傳原數值

Sample Case:

1 → 1
2 → 2
3 → Fizz
4 → 4
5 → Buzz
6 → Fizz
7 → 7
8 → 8
9 → Fizz
10 → Buzz
11 → 11
12 → Fizz
13 → 13
14 → 14
15 → FizzBuzz

怎麼開始

首先是時間，專案很忙碌，不是所有的人都有空，
我要怎麼擠出時間 ？

利用 TimeBox 與 Don’t Break The chain

每天都練習 KATA，每次 30 分鐘；
每天約定一個時間 30 分鐘，30 分鐘到就強制結束，
不論是中午的 30 分鐘，或是下班前的 30 分鐘，
找一個時間只要有兩個人的時間 OK 就進行 。
輪流當 Driver 與 Navigator ，時間設定 5 分鐘，
一樣時間到就換手。

嚴格執行 TimeBox 真的是一件很折磨人的事情，
特別是有一些火花的討論出現時，
但是隨著每次的 TimeBox 的結束，
看到的成果比上一次多時，
那種進步感是相同明顯的。

很幸運的，一直到過農曆年我們都沒有中斷，
設定 TimeBox 也確實有讓參與的人提昇，
包含「重構的技巧」、「打字」、「TDD」與「Vim」，
也有人分享工具，或是小技巧，
這達到我們彼此學習的目的。

回顧一下作得好的部份

1. 雖然很困難，有線上的問題要處理，有工作項目，有一堆會議，但是我們仍然沒有中斷過一天。
2. 完成了兩個 KATA ，經典的 FizzBuzz 還有很類似的題目 FooBarQix。
3. 確實有從彼此身上學到東西，比如說在 Vim 裡面超好用的 ci 或是 AceJump 小工具。
4. 人數控制的很好，押在 3 到 5 人，也讓大家都能參與到。
5. 最重要的一點，看到了很多「真實」

作得不好的部份

1. 環境有一些前期門檻在，ex: Reshaper、已配置過的 VimRC
2. TimeBox 有時候仍會超過，主因是討論太熱情了。
3. 整體成員都算有經驗的開發者，但是對重構仍然很弱，對壞味道麻痺(不在意重複等…)
4. TDD 有時候沒辦法作到 Baby Step ，雖然重構是成功的，但過程有點跳躍；或是重構完才發現測試壞一大片，需要偵錯去修正。
5. 雖然有記錄一些問題，但是常常沒有去求解答

真實的部份

1. 我們常常看到重複視而不見，特別是只有兩、三次的重複
   • 這題成員的看法比較貼近大量重複再重構…我仍然有點持疑
2. 因為時間壓力，我們會把問題留給後人；我們不會去理解前人的設計
   • 時間壓力可以換成任何理由
3. Navigator 如果沒有思考 Driver 會開 Auto

我們開發者真的太有自信，在 KATA 過程出現的問題，
如果放到開發現場的規模，基本上就是災難，
而實際上也是每天發生。

在時限的壓力下，你不能作出多完美的設計，
但是你可以透過測試作出足夠好的設計，
測試的保護可以幫助你提早發現

下一步是

一直以來有那麼多讀書會，上了那麼多課，
也有外訓內訓，結果卻是不了了之，
要怎麼証明理論有效 ？
要怎麼導入開發現場 ？

我們的成果

寫在後面

我不是本科系畢業，但在軟體開發上也有 7、8 年的經驗，
軟體的經典書籍也看過不少，
不論是免費的社群活動或是上萬元的課程，
相關的課也上了不少。

學習單一語言的特性或是設計模式、物件導向到工程上的 Code Review、Pair Programming、TDD 諸如此類等…
不能說沒有幫助，但總覺得現實與書上的理想好遠啊…
我以為我懂了，其實我根本不懂。

技術不斷推陳出新，追不勝追，
常常工作完後研究或是練習到半夜，
但是沒什麼效果，或在實務上根本用不到
真得很有事倍功半的無力感。

在工作上的產品或專案永遠都有緊急又重要的事要作，
人家的艾森豪矩陣有四個象限，你永遠只有一個象限，
生活上各種的壓力與瑣事，變成了種惡性循環，
像個泥沼一般，無法提昇所以下沉，下沉了更無法提昇。

這個小小實驗，就像是整個開發現場的濃縮版，
現場很多問題不是沒有解答，
但是常常一句「理論上是，但是…」，然後就沒有然後了。
我們太習慣短解，太過自信，讓不好的事情重複發生，
然後覺得自已很忙碌，很有價值感，
但是沒有任何改變。

這個實驗我會繼續下去，期待能有好的結果，並帶來一些變化。

參考

• marsen/Coding_Dojo_Csharp
• Coding Dojo

(fin)