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