一切由測試開始 - 業界資訊 [複製鏈接]

晚安天使

Teenager I

Rank: 7 Rank: 7 Rank: 7

好友: 0
帖子: 4565
積分: 9101
最後登錄: 2018-7-30
在線時間: 0 小時

電梯直達

樓主

發表於 2013-9-25 22:05:59 |只看該作者 |倒序瀏覽

開發軟件有很多原則，其中一條是 YAGNI，You ain’t gonna need it，意思是只開發需要用到的東西就好了，不要想太多。可惜偏偏越有經驗的開發者，越會想得多，這段代碼日後如何維護？有沒有效能問題？需要 logging 嗎？日後可能要 transaction？然後就會做很多預備功夫，「留位」以應付日後改變，又然後很久所其之改變沒有來，再然後那些代碼日漸腐化。
YAGNI 的原因，是要做到 simple design，不要將不必要的複雜性引入程式裏。但日後的改變要如何應付呢？YAGNI 背後其實有很多「配套」，總稱是 incremental design，方法是常用 refactoring 改善設計，減少重複，本身體質良好的話，就能擁抱改變。
Refactoring 理論上是用一連串簡單且可控制的代碼改動，只做到內部結構重組，但外部行為不變。但實際上如此改動仍是有風險的，所以一般講 refactoring 的都提醒大家，要有測試做覆蓋。每做一個改動，就執行一次測試，看看有沒有改爛了東西。有了這安全網，refactoring 就變得可以常常做了，設計也能經常改善。
這堆測試當然是在開發時寫，或甚是開發之前就寫，也就是 test-driven developement (TDD)。傳統古法先寫代碼，再寫測試，是相當沒趣的，開發者會想直接執行代碼，而沒有誘因去寫測試。先寫測試見紅，再寫代碼見綠，然後 refactor 是 TDD 的基本步1。通過一小步一小步，每幾分鐘就知道自己剛寫的沒錯能執行，而且還得了一堆測試，日後有用。不過提倡 TDD 者經常提醒大家，寫測試只是做設計的手段，不是目的。用 TDD 思考本身就會改變代碼的寫法，所寫的要能單獨被測，元件鬆散耦合。
以前有人問到經典《設計模式》四人幫之一的 Erich Gamma 有關設計模式那種預先佈陣以期改變的做法，有違 simple design 原則。他也說做 up-front design，杞人憂天其實成本昂貴，而 XP (extreme programming) 的人做得才對。XP 人沒有放棄用設計模式，只是用不同手段達成而已。XP 用 TDD 設計，備有測試後就可以安全 refactor，並應用設計模式。
所以說到尾，一切都是由測試開始。