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