2009年3月10日 星期二

TDD 推廣:結語和參考資料

前篇,這篇說明我和組員近兩週開發過程中的心得,並附上幾篇不錯的參考資料。

結語

目前我和組員只有做到半套的 TDD,有時有照三步驟的順序進行,有時是先寫程式碼,再補測試碼,或兩者交替寫。目前組員有感受到測試程式的好處,例如對程式有信心、避免因修改而破壞既有功能。組員也漸漸感受到重構的必要性。但對於先寫測試碼這點,仍有疑慮而難以進行。至少,我們盡量遵守 TDD 的結果,在寫另一個 class 時,會先補好測試碼,保持程式碼的品質。附帶一提,配合 IDE 的功能,先寫測試碼可以輕鬆地建出產品用程式的框架。像 Eclipse 可以自動產生不存在的 class、method、field,所以我常先寫測試,再用 Eclipse 建出這些東西的殼,之後再填入內容,寫起來相當快。

開發過程也不盡是順利。藉由頻繁的 code review 組員的程式碼,還有回顧自己的程式碼,我發現許多問題。像是單一測試函式太大、測試碼和程式關聯性過高、測試時間過長,若沒有第一時間更正,後果不堪設想,也會使得組員對 TDD 有不當的負面認知。這方面的相關知識可以搜尋 TDD antipattern,或 JUnit antipattern

此外,由於組員少了前備知識,進行開發過程裡會看到許多 code smell,常常在重構一段程式前,必須先重構另一段程式,而重構另一段程式前,又得先補對應的測試程式或重構測試程式。這才體會到良好品質的程式碼得來不易,需要全組成員一同堅持和維護,大家的相關知識也需要一同逐步提昇,才能達到良好的軟體開發流程。雖然初期摸索很花時間,相信日後會有相當高的回報。

說了這麼多,其實仍抵不過自己親身嘗試,強力建議親身找個小專案,用 TDD 的三個步驟寫個千行程式,相信程式設計思維會有很大的轉換。

參考資料

我到 slideshare 找了一陣子,看到三份不錯的教學,但各有些不足,沒有一份完全符合我預期的入門文件。若有時間的話,自己再來作份投影片。

相關閱讀

沒有留言:

張貼留言