從最近遇到的幾個故事說起.

故事一:
某天晚上和室友聊天,談到使用Vim閱讀代碼,室友也是使用Vim的人,他說用類似ctags的查找定位功能不多,更多的時候,他閱讀一段代碼,要定位一個功能點,首先是從閱讀代碼文件的組織,了解項目的功能等入手,等這些都基本清楚了,定位起來就會快很多.我雖然認(rèn)為,ctags實在是Vim里面一個很不錯的功能,不用這個實在可惜,但是他說的那套定位思路其實也是不錯的方法.其實我自己用慣了ctags類的功能之后,閱讀代碼的時候也會用惰性,更多的時候是要靠這些工具來幫我定位,而不是通過自己主動的思考和分析.

故事二:
我的經(jīng)驗里面,寫完一段代碼之后的第一次編譯,如果編譯器報錯越少,那么可以認(rèn)為這段代碼將來可能出現(xiàn)bug的幾率越小,簡而言之,我認(rèn)為代碼的質(zhì)量與第一次編譯的報錯數(shù)量成反比(哦,不用拿helloworld類的程序跟我鉆牛角尖了:).有些人寫的代碼,嘩嘩的寫了一大段,寫之前不考慮好,只想著到時候?qū)懙牟粚α丝梢栽诰幾g由編譯器的報錯來幫忙找問題,這個思路是不對的.編譯報錯越少的代碼,說明了作者寫的時候思路更清晰一些,考慮的更周全一些,所有的這些流程上的步驟走的都不錯了,所以才有最后編譯報錯少的結(jié)果.編譯報錯應(yīng)該是寫代碼的結(jié)果之一,而不應(yīng)當(dāng)當(dāng)成了找代碼問題的手段,這樣的思路,本末倒置了.

故事三:
進入新項目組后,組內(nèi)對代碼編碼的流程有比較嚴(yán)格的要求,包括寫一個API之后需要寫一個針對這個API的各種情況的測試用例,提交代碼的時候,需要走codereview流程,需要使用cpplint檢驗代碼風(fēng)格,需要將對應(yīng)的測試用例也提交上去.這一套流程走下來,提交代碼的頻率比之以前,降低了很多,但是不可否認(rèn)的是,也確實提高了代碼的質(zhì)量.假設(shè)一個功能,由N個API構(gòu)成,如果能對這N個API都做過詳細(xì)的測試,保證它們的輸入和輸出在各種情況下都能符合要求,那么很顯然的,最后這個功能也應(yīng)該是正確的.反之,越是到了測試階段需要使用類似gdb這樣的調(diào)試器來定位問題的,會越讓人不放心---因為沒有制度和流程的保證,誰也不能說將來可能在哪個點會出問題.它可以幫你定位問題,但是沒有辦法告訴你已經(jīng)沒有問題了,最后這一點,最終還是要通過嚴(yán)格的單元測試等流程來保證的.與第二個故事相同,我認(rèn)為,在測試階段使用gdb定位問題的次數(shù)也與代碼的質(zhì)量成反比:)

這幾個故事綜合起來,想要表達的是,做一件事情,需要有流程,制度的保證,當(dāng)然也需要工具(比如這幾個故事里面提到的Vim,gcc,gdb),但是工具就是工具,它只是一種手段,沒有辦法替代正確的思路,流程和制度等,僅能在整個過程中起到輔助的作用.而且,過分依賴工具,也會給人以惰性(比如前面提到的使用編譯器編譯代碼來找錯,比如使用gdb來保證功能正確性等).

所以,更應(yīng)該提倡的是正確的流程,制度,有了這些,項目的質(zhì)量才能有所保證.比如,在寫一個功能點時,需要具體分解為哪幾步,每一步有哪幾個API,針對它們的測試用例有哪些,測試時的輸入和輸出有哪些,需要考慮的異常情況有哪些,等等的.這些都考慮清楚了,再動手寫,久而久之,我想這方面的能力會慢慢的提高.