學習 TDD 必看的聖經本，當然就是 Kent Beck 的 TDD by Example。在取得 Kent Beck 授權之後，將書中每一步程式碼的演進，都放到 GitHub 的 commit history 上分享給各位讀者參考，讓大家既能專注在每一步的變化，又能兼顧全局，還可以在任何一步的 sample code 繼續往下練習。
作者: 91
生產力 = 你的設計功力（能力） + 最佳化開發環境與設定（神兵） + 對的開發方式（招式）
【極速開發】就是用來解決實務上大家總說「時間不夠」的問題，因為時間不夠，所以我沒法子寫單元測試，沒法子重構，沒法子 TDD，沒法子 code review，沒法子把事情作到最好。
我認同「時間不夠」是個問題，然而卻很少人去改善或解決這個問題。各位將會從此學到，如何建立自我刻意練習的模型，將所有工具的整合起來發揮最大綜效，透過正確的開發方式與順序，讓你寫代碼時能行雲流水，並且兼顧設計、品質與生產力。
活動以 Coding Dojo 方式進行，挑選合適的 Kata 當需求，帶著大家分組進行需求的釐清、測試案例探索、實例化需求、設計與分析。
【6/5 更新】7/3(六)活動取消 很遺憾通知各位，熱血 Coding Dojo – 202102 台中（延 […]
在 Mac OS 上使用 IDE 無法用 Opt + shortkey 來選擇想要點選的功能嗎？只要加一行設定就可以讓你正常使用 mnemonic 的便利性囉。不用再為了這件事，而得讓雙手離開鍵盤，只為了用滑鼠點那個被該死的智慧輔助鍵盤擋住的功能。
公司對新人到職三個月是怎麼安排的呢？給一堆投影片叫他自己看，然後報告？給他知識管理系統連結，要他自己去看？還是上幾次課，然後考試呢？給他無關緊要的ticket讓他修嗎？如果你希望新人用最短時間融入團隊真實工作，請試試看透過 pair programming，效果顯著。
從陪小孩寫功課的過程，了解 code review 與 pair programming 的差異。code review 是個落後指標，發現問題的時間點越晚，修復成本就越高。而當 code review 淪為線上稽核的形式，往往在往返之間的誤解、等待就會造成極大的浪費。
讓大家依據實務需求完成代碼、加入單元測試、code review 、code smells 辨識，且依照成員的 legacy code 現場示範重構並指導練習重構、測試案例探索/分群/排序、邏輯樹拆分、TDD 循環與 baby step、迭代堆砌產品代碼增量。
單元測試是開發軟體產品過程中，與品質、設計相關最重要的基本工程實踐，如果不會單元測試，很多重構無從下手。如果不會單元測試，無法駕馭測試驅動開發。
生產力 = 你的設計功力（能力） + 最佳化開發環境與設定（神兵） + 對的開發方式（招式）
【極速開發】就是用來解決實務上大家總說「時間不夠」的問題，因為時間不夠，所以我沒法子寫單元測試，沒法子重構，沒法子 TDD，沒法子 code review，沒法子把事情作到最好。
我認同「時間不夠」是個問題，然而卻很少人去改善或解決這個問題。各位將會從此學到，如何建立自我刻意練習的模型，將所有工具的整合起來發揮最大綜效，透過正確的開發方式與順序，讓你寫代碼時能行雲流水，並且兼顧設計、品質與生產力。