記得剛到公司做第一個項目時,mentor要和我一起看看我剛實現完的一些代碼,當時有些不解,難道是不相信我寫的代碼嗎?最後事實證明:My Code中有很多缺陷,有的還是很嚴重的缺陷。後來知道這個過程叫'程式碼檢閱',是保證軟體品質的一種手段,而且是很重要的一種手段。程式碼檢閱的形式有多種,最正式的一種就是召集公司或者部門的一些'大牛'們,圍坐在會議室中,一行一行的審查你的代碼;簡單的形式就像我和mentor做的那種,一個編寫代碼的人和一個對系統特別瞭解的人在一起評審,效果不見得不如正式的評審,起碼我是這麼認為的。
那麼什麼時候進行程式碼檢閱呢?程式碼檢閱的粒度又該如何確定呢?一般在你的代碼已具雛形,並且已通過單元測試,未提交進行整合測試之前的這個時機。評審的粒度要看代碼的規模,當然評審的代碼覆蓋面越大,代碼的品質越有保證。對於涉及商務程序較複雜的模組一定要和熟悉業務的人一起完成代碼的評審,對這類別模組應給予重點關注,因為往往商務程序邏輯的錯誤多於語言使用的錯誤。還有一個時機建議作程式碼檢閱,即在系統第一版發布後,如果有需求變動需要增加新功能,記住這時程式碼檢閱的效果可能好於簡單的測試,當然兩者都要有才能保證代碼品質更高。
粗略的想了一下,程式碼檢閱有以下幾點好處:
1、程式碼檢閱會儘可能的將Bug殺死在萌芽階段
實踐證明:項目先期發現Bug的成本要遠遠小於後期發現Bug的成本,越早發現代碼中的問題對整個系統的控制和把握就越有利。
2、程式碼檢閱的過程是一個知識技能傳承的過程,有利於新人成長
程式碼檢閱類似於師傅手把手教徒弟,是知識、技巧和經驗的直接傳授,所以這樣的機會是很難得的,特別是對於新人,要十分珍惜程式碼檢閱這樣的機會,新人在這個環節中學習的效率和成果實踐證明也都是最高的。
3、程式碼檢閱會讓你加深對系統的理解
程式碼檢閱的過程實際上也是從新梳理思路的一個過程,特別是對於那些商務程序複雜的模組,和精通業務的人一起做程式碼檢閱可以讓你加深對業務和系統的理解。
總之,程式碼檢閱是必要的,而適當的加大程式碼檢閱的粒度,你將會收到意想不到的效果。