|
|
有一本書就叫<<測試驅動開發>> , 我沒有看過,這里僅談論我所理解的"測試驅動開發".
我對這句話的理解是:
1) 任何一次提交新的代碼都需要添加針對這些新功能的測試用例
2) 無論設計函數還是類, 對外暴露的接口都應該做到明確, 清晰, 不會給人模棱兩可的感覺,提供的功能點盡可能的單一, do one thing, do it well.
簡而言之, 我所理解的"測試驅動開發", 十分強調對接口的設計, 以及針對這個接口所需要考慮的異常和測試用例.接口是對外的保證, 而測試用例是驗收者, 每次的修改, 都需要保證之前和現在的用例能順利通過.
所以, 對開發人員來說, 如果有這個"測試驅動開發"的觀念, 那么在設計編寫代碼的時候會很容易的形成幾個好習慣, 比如他會反問自己以下幾個問題:
1) 新增的代碼提供的是什么功能? 功能點是否足夠的單一, 明確, 比如本次測試的代碼僅針對功能A, 下一次的僅針對功能B, 假如B功能還依賴于A功能, 那么首先要保證A功能點正確提交.切忌萬不得已的情況下不可以將多個功能點放在一次提交中, 這樣, 以后回溯問題時會加大難度, 也會給codereview等帶來困難.
2) 新增的功能, 對外暴露的接口是哪些?有沒有冗余, 不明確的接口設計?這些接口是不是剛剛好不多不少足夠了?
3) 對新增的功能, 明確了對外應該提供什么接口之后, 還需要反問自己:可能在哪些情況下出錯, 每種出錯的情況應該如何處理, 如何通知調用者, 代碼的注釋是不是對一些情況作了說明.
4) 最后, 對新增的功能, 考慮了哪些測試用例, 測試是否充分, 是否考慮了很多異常的情況?
所以, 每次的代碼提交都是一件很嚴肅的事情, 這意味著, 你對系統現有的代碼做出了一些修改, 可能是接口的修改, 可能是實現的修改.如何能保證你的修改沒有問題, codereview是一點, 好的codereview是一件很耗時的事情, 這需要reviewer負責任,同時最好還要多少對這部分代碼有了解.如果reviewer能力較強, 又比較負責, 那么一次review相當于是一個老師在閱讀作業, 他會給出你一些建議;反之, 如果你作為reviewer去review一個高水平的人的代碼, 又可以從閱讀中學習對方的思路.總而言之, 我覺得做好codereview是一件能夠迅速提高"經驗值"的捷徑, 早前我閱讀過許多開源項目, 學習了很多別人的技巧思路, codereview比之更近了一步--因為我還有機會與作者面對面的一起交流.另外, 除了codereview之外, 每次提交都有測試用例, 也是保證代碼質量的方式之一, 如果把代碼比做一個球場, 那么測試用例就是站在這個球場門口進行安檢工作的保安, 不論做了什么修改, 只要保證測試用例寫的好, 那么基本上都跑不過這個保安的掌心.有了測試用例, 項目的修改才有了保證, 它所提供的功能, 都是可控的,有保證的.
另外, 每次提交的修改功能點盡量的單一也是很重要的一點, 因為假設你想做的事情很多, 比如做了A又想做B,發現做B功能需要實現C功能,實現C功能首先要做D功能....子子孫孫,無窮盡也.這樣會導致你的代碼提交codereview時被通過的時間慢(原因有很多, 比如你需要提交測試用例多了, 比如別人的codereview時間多了).還有一點, 假如別人趕在你之前提交了代碼, 而你的修改需要依賴別人的代碼, 這樣導致了你需要合并別人的改動, 這又是一件很麻煩的事情.
所以, 當接手一個任務時, 如何按照層次順序劃分任務, 每次提交都保證盡可能提交少的功能點, 而且又能保證每次的提交都有嚴格的測試用例, 也是對開發人員的一個考驗.當然,這些也許在動手的時候不能百分百的考慮清楚, 但是如果完全的沒有考慮過, 上手就做, 遲早都要還的.
另外, 有了同新增代碼一起提交測試用例的要求之后, "看上去"每次提交的速度慢了, 因為還需要撰寫測試用例, 所以對任務時間點的估計可能也需要改變, 我個人的估計是寫代碼時間 : 測試時間(包括寫測試用例+改bug) : 根據codereview修改代碼的三者之間比例大概為4:3:3, 所以如果一個任務給我五個工作日的時間完成, 也許以前我到了第四天才編碼完成, 而現在就要盡量做到第三天之內能完成編碼了.不過這個比例并不確定, 依個人的素質而定, 有的人寫代碼質量很高, 自己已經把很多情況在寫的時候考慮進去了, 所以后期測試和codereview時出現問題的機會少, 反之, 有的人的代碼質量較差的, 可能經常在codereview的時候被打回去重構(甚至于重寫)的, 后面的比例就要增加了.以我而言, 如果能在保證代碼質量的同時, 減少后面兩項的時間比例, 那應該是說明了我的代碼質量有了提高了.
總而言之, 接口的設計, 任務層次順序的劃分, 都是很考驗人經驗的活, 語言的表達總是蒼白的, 需要實實在在的去實踐體會.
K.I.S.S
|