如何堅持TDD──使用者出現的問題以及解決方案

關鍵字：TDD 問題 解決 方案

　　我們組織里曾有許多團隊努力采用測試驅動開發(TDD)[1]。偶爾會有一兩個開發者成功，但是大多數都失敗了。為了更好地找出原因，我調查了團隊 的一些成員，發現即使經過了課堂培訓，還有更多的事情需要做。雖然這里介紹的問題和想法只適用于中大型的公司，但理解這一點能夠幫我們在組織中更好地引入 TDD。

　　我對組員(他們全都接受過培訓)的調查顯示，以下問題影響了他們：

　　由于經驗不足，大家發現自己直接TDD比較困難。

　　TDD培訓的例子比實際應用簡單得多。

　　需要更多的時間來實驗和嘗試，不要有趕緊發布軟件的壓力。

　　實際中應用的語言，比如Visual Basic和JavaScript，在單元測試文檔或者課堂練習中從來不會用到。

　　常常會碰到很多遺留代碼，而培訓時不會介紹如何改進這些代碼。

　　永遠沒有足夠的時間用來學習──隨時都有盡早交付產品的(人為的)壓力，于是沒有時間學習提高自己。

　　隱藏的問題

　　我們已經列舉了這么多癥狀，那么冰山下面隱藏的問題是什么呢?

　　測試驅動開發并不是很難學。學習階段(指形成根深蒂固的習慣的這段時間)一般會持續2到4個月，期間生產效率有所降低[2]。最終的好處顯而易見，開發者也能自己保持該項技術，但問題是：怎么才能做到這樣?很多開發者僅僅幾天之后就放棄了。

　　就我見過的方法而言，大多數依賴于課堂培訓(或者e-learning)和一對一的輔導。如果做得好的話，這些方法當然不錯，可以作為整個解決方案的一部分，但是我認為還需要更多的方法。

　　課程培訓有兩個主要的問題：例子太簡單，與實際問題關系不大;給大家練習的機會不多。

　　在線培訓(Object Mentor和Industrial Logic，以及其它機構提供的培訓)，其優點是更有深度。然而練習的機會仍然不多。而且在這些課程里，你與其他學生通常沒有交互。聽一聽你同學和同事的問題，能夠加深你的理解。

　　一對一的輔導只能用于團隊中的幾個人，很難推而廣之。在大型企業里面，專家只有幾個，而需要幫助的人有成千上萬，所以一對一的輔導更是困難。

　　看書是個很好的方法，但是很少有開發者喜歡通過讀書學習TDD技術，即使有些人發現看書可以緩慢提高其TDD水平。與其它在線教程類似，看書仍然是只能一個人學習。

　　最后：遺留代碼使得TDD難上加難。開發者當然會問這樣的問題：“這些對象緊密耦合，怎樣才能測試它們?這些代碼太復雜了，怎樣才能測試這個算法?”

　　一個解決方法

　　那怎樣才是好的解決辦法呢?前面的方法主要有兩個問題：沒有深度、缺乏協作。一個完整的解決方案需要結合使用多種學習模式，并需要包含以下多種因素。

原文轉自：http://www.kjueaiud.com