衆所周知，Bob大叔是敏捷式開發的發起者與踐行者。對於如何保證代碼質量，他推崇的是測試驅動開發方式（TDD）。
TDD的實踐原則說起來也就是三項，而且很好理解：
- 在編寫好失敗的單元測試之前，不編寫任何業務代碼；
- 只要有一個單元測試執行失敗，就不再寫測試代碼，必須將當前的問題解決掉；
- 業務代碼恰好能讓當前失敗的單元測試通過即可，不用多寫。
TDD的好處很多，首先就是讓開發者對代碼的質量具備了充分的信心。一個正式商用的系統一般都會包含數量衆多的功能模塊，百十來行代碼還能顧得過來，到了數千行代碼的時候，要想加個功能改個參數難免心裏打個小鼓。而完備的單元測試可以避免這種擔心，不放心跑一遍單元測試用例，有問題就解決，沒問題就繼續。
其次是單元測試用例本身就是最好的功能說明文檔，這對於協作開發或是代碼交接都是最省時間的。在傳統的軟件開發過程中，總會強調完備而詳細的文檔，但問題在於文檔的編寫總是滯後於代碼的實現。沒有人希望自己看到的是一份過時的文檔，都想直接從代碼入手來了解系統實現。顯然，單元測試用例就是從系統的底層描述了最小粒度的代碼實現。
再次就是TDD對於良好設計的倒逼作用。可能一位開發人員要經過很長時間的磨鍊才能具備良好的代碼設計能力，做到松耦合、正確使用設計模式等。如果遵循TDD開發方式，則非常有助於培養良好的設計能力。因爲糟糕的代碼實現意味着難以編寫單元測試，諸多功能耦合成一個無法測試的大塊代碼區。這就會促使開發人員思考如何進行分解並且使用設計模式。
當然，敏捷方法大都是說起來簡單，但做起來不容易的。對於TDD來說也是如此，它需要開發人員的嚴格自律與高度認同。即發自內心地認可並在任何時候都堅持原則。最常見到的一個場景就是老闆催得急，開發者心想：“哪還有時間寫測試代碼，趕緊直接做業務實現，等有空了我再補上吧。”。就此小坑就挖成了大坑，又回到我們熟悉的加班-改bug痛苦輪迴中。
要想做到在實際工作中不因爲各種理由而違背原則，進行刻意的練習是非常有必要的。借用中國人民解放軍常說的一句話就是：平常多流汗，打仗少流血。幸好在網絡上還是有很多資料可以使用的，卡塔練習就是從武術中借用的一個術語，意即固定的招式。當然，同樣的招式練得好的可以飛花逐葉，踏雪無痕；不肯下苦功夫的只能打個醬油跑個龍套了。
資源鏈接：
http://katas.softwarecraftsmanship.org
http://codekata.pragprog.com