很長時間沒有自己寫博客了，前兩個月看了一些關於測試驅動開發（Test-Driven Development, 簡稱TDD）和敏捷軟件開發（Agile Software Development）是否有用、是否一定得用的爭論，很精彩，也很引人思考。尤其感謝酷殼網的站長陳皓先生將這些觀點蒐羅起來並發表了自己的看法。
在我的同事（尤其是小利）面前，我一直裝着是個敏捷的忠實粉絲，但是嚴格的來講，任何一種開發方法學都不能強制的推廣到所有開發者的身上。一個磨合良 好的團隊應該以人爲出發點，而不是以規則。不同風格的開發者在一系列鬆散的規則下互相磨合的工作，纔是健康的一個開發循環。
我很難相信，有很多沒有做過項目甚至不曾鑽研技術的人去做敏捷諮詢師。儘管一直很想做技術諮詢業，但是一直對這個敏捷培訓行業沒有太多深入的瞭解。有朋友如果對敏捷諮詢這種行業有自己的見解，那麼我是急於認識的。
敏捷軟件開發那個話題太大，尤其是非技術面的觀點融入進來之後，容易變成清談，所以今天先不提。着重說一下對測試驅動開發的看法。TDD存在的主要問 題就是，如果需求不是很明確，或者需求提出方變動特別頻繁，那麼回導致測試代碼頻繁的變更，從而減緩甚至干擾工程進度。還有就是特定開發人員的思維與 TDD的流程磨合不融洽。所以並不是一定要強制進行TDD。測試並行、測試後行都是可以被接受的。但是應當給全體團隊講授TDD思想和技術，因爲其中一些 特定細節，比如邊界值檢測，按契約編程，前條件、後條件測試，對於非TDD測試照樣可用。
相比強制推行TDD而導致的低效，另外兩種做法則是更不能容忍的。一種是等代碼邏輯全部完成之後，匆忙補寫測試用例，並且只測試想當然的情境，得出 “果然成立”的結論後，就匆忙提交了。例如寫一個ArrayList，測試了add(Object)方法前後的size大小是否差1，就認爲add方法實 現正確了，根本不管add(null)或者多次add同一個引用時是否結果正確。這種態度就是事先擬定了一個“正確”的路徑，然後沿着這個路徑草草寫就一 個測試用例，不管其它路徑。是一種不負責任的態度。質量管理人員或者團隊成員有義務阻攔這種代碼進入代碼庫。如果因爲工期的關係必須出產品，那麼官方的主 幹版本也絕不應該允許這種代碼入庫，至多隻能提交到beta分支上。待原作者補完合格的測試後，再行併入主幹。
另一種則是根本不進行任何測試，等待一個集中的時間補寫，例如產品3.0版本發佈後抽出一週專門補寫。這種規劃基本是精神勝利法式的管理。自認爲測試 已經在精神上被“寫完備了”，只是沒落到代碼上而已。然而在實際的工程裏，根本不會有任何人再去補寫這部分測試了，所有人會立刻投入下一個版本或產品的開 發中去。
比較穩妥的辦法是當代碼主路徑及一些支流路徑初具規模時即開始着手規劃測試，然後通過測試來完善代碼流程中的疏漏，同時根據代碼流程的變化（可能是需 求變更引發的）來更新測試用例。這時代碼和測試基本處於穩定狀態，管理起來也比TDD風險小很多了。總之，團隊成員的測試警覺度和技術管理者對測試代碼質 量的高要求可以淡化TDD的強制性，作出一種柔性測試的氛圍。這對於團隊的磨合是有益處的。
關於如何寫好測試的問題，我閱讀還不是很深入，初步可以肯定有價值的資料除了Kent