從最近遇到的幾個(gè)故事說起.
故事一:
某天晚上和室友聊天,談到使用Vim閱讀代碼,室友也是使用Vim的人,他說用類似ctags的查找定位功能不多,更多的時(shí)候,他閱讀一段代碼,要定位一個(gè)功能點(diǎn),首先是從閱讀代碼文件的組織,了解項(xiàng)目的功能等入手,等這些都基本清楚了,定位起來就會(huì)快很多.我雖然認(rèn)為,ctags實(shí)在是Vim里面一個(gè)很不錯(cuò)的功能,不用這個(gè)實(shí)在可惜,但是他說的那套定位思路其實(shí)也是不錯(cuò)的方法.其實(shí)我自己用慣了ctags類的功能之后,閱讀代碼的時(shí)候也會(huì)用惰性,更多的時(shí)候是要靠這些工具來幫我定位,而不是通過自己主動(dòng)的思考和分析.
故事二:
我的經(jīng)驗(yàn)里面,寫完一段代碼之后的第一次編譯,如果編譯器報(bào)錯(cuò)越少,那么可以認(rèn)為這段代碼將來可能出現(xiàn)bug的幾率越小,簡(jiǎn)而言之,我認(rèn)為代碼的質(zhì)量與第一次編譯的報(bào)錯(cuò)數(shù)量成反比(哦,不用拿helloworld類的程序跟我鉆牛角尖了:).有些人寫的代碼,嘩嘩的寫了一大段,寫之前不考慮好,只想著到時(shí)候?qū)懙牟粚?duì)了可以在編譯由編譯器的報(bào)錯(cuò)來幫忙找問題,這個(gè)思路是不對(duì)的.編譯報(bào)錯(cuò)越少的代碼,說明了作者寫的時(shí)候思路更清晰一些,考慮的更周全一些,所有的這些流程上的步驟走的都不錯(cuò)了,所以才有最后編譯報(bào)錯(cuò)少的結(jié)果.編譯報(bào)錯(cuò)應(yīng)該是寫代碼的結(jié)果之一,而不應(yīng)當(dāng)當(dāng)成了找代碼問題的手段,這樣的思路,本末倒置了.
故事三:
進(jìn)入新項(xiàng)目組后,組內(nèi)對(duì)代碼編碼的流程有比較嚴(yán)格的要求,包括寫一個(gè)API之后需要寫一個(gè)針對(duì)這個(gè)API的各種情況的測(cè)試用例,提交代碼的時(shí)候,需要走codereview流程,需要使用cpplint檢驗(yàn)代碼風(fēng)格,需要將對(duì)應(yīng)的測(cè)試用例也提交上去.這一套流程走下來,提交代碼的頻率比之以前,降低了很多,但是不可否認(rèn)的是,也確實(shí)提高了代碼的質(zhì)量.假設(shè)一個(gè)功能,由N個(gè)API構(gòu)成,如果能對(duì)這N個(gè)API都做過詳細(xì)的測(cè)試,保證它們的輸入和輸出在各種情況下都能符合要求,那么很顯然的,最后這個(gè)功能也應(yīng)該是正確的.反之,越是到了測(cè)試階段需要使用類似gdb這樣的調(diào)試器來定位問題的,會(huì)越讓人不放心---因?yàn)闆]有制度和流程的保證,誰(shuí)也不能說將來可能在哪個(gè)點(diǎn)會(huì)出問題.它可以幫你定位問題,但是沒有辦法告訴你已經(jīng)沒有問題了,最后這一點(diǎn),最終還是要通過嚴(yán)格的單元測(cè)試等流程來保證的.與第二個(gè)故事相同,我認(rèn)為,在測(cè)試階段使用gdb定位問題的次數(shù)也與代碼的質(zhì)量成反比:)
這幾個(gè)故事綜合起來,想要表達(dá)的是,做一件事情,需要有流程,制度的保證,當(dāng)然也需要工具(比如這幾個(gè)故事里面提到的Vim,gcc,gdb),但是工具就是工具,它只是一種手段,沒有辦法替代正確的思路,流程和制度等,僅能在整個(gè)過程中起到輔助的作用.而且,過分依賴工具,也會(huì)給人以惰性(比如前面提到的使用編譯器編譯代碼來找錯(cuò),比如使用gdb來保證功能正確性等).
所以,更應(yīng)該提倡的是正確的流程,制度,有了這些,項(xiàng)目的質(zhì)量才能有所保證.比如,在寫一個(gè)功能點(diǎn)時(shí),需要具體分解為哪幾步,每一步有哪幾個(gè)API,針對(duì)它們的測(cè)試用例有哪些,測(cè)試時(shí)的輸入和輸出有哪些,需要考慮的異常情況有哪些,等等的.這些都考慮清楚了,再動(dòng)手寫,久而久之,我想這方面的能力會(huì)慢慢的提高.