常飄在天上的程式碼檢閱

雖然Code Review經常被提及，但就我個人感覺（一半從別人的部落格，一半個人經曆），Code Review的實際境況大多時候還是比較難看的。

更多時候，Code Review很像被存起來的酒，用的時候拿出來看看，證明有這東西，但大多時候是不用來喝的。

 

細究成因可能是來源於兩個方面：

一是時間壓力太大。

軟體開發裡可以安全打折扣的地方其實不多，文檔不寫很容易被看出來，代碼不寫程式就動都不動了。

沒辦法下，很多時候就只好拿Code Review開刀。

畢竟Code Review裡少看兩眼，多看兩眼，用多少心思看，其實是個良心賬，外人看不出來的。

同時，Code Review本身也確實是個費時間的活。

 

另一種成因是看不見成效。

如果把CodeReview只等價為坐在一起看代碼，那麼很可能Code Review中確實無法取得實效，這樣做來做去，大家也就疲了，覺得這是個浪費時間的事情。

這點和上一點有點關聯，一旦時間緊，就要求編碼快；編碼快，對具體某一個人而言，不理解的部分就變多；再加上無法預留充足的Code Review時間。

那麼，除了作者外，參加Review的人對看的代碼很可能是不懂的。不懂的話，也就只能糊弄，隨便找點問題搪塞下。

從這個角度看，追求高生產率應該是錯誤的，生產率本身應該是個區間：低於某一值的是磨洋工，高於某一值的則是品質換速度。

畢竟人力有時窮盡。

 

 

單就項目時間壓力這一點而言，通常並不能在項目自身範圍內解決，牽涉的也比較多，暫且不論。

 

看不見成效這點卻可以想點辦法來改善。

改善的一個主要手段是要明確“不看什麼”和“看什麼”。

需要注意的是，大多時候“定義不看的”很可能比“定義需要看的”還關鍵。

當然這裡的前提是“時間壓力下，儘可能擷取成果。”如果一個項目有的是時間，那就不妨把每行都找幾個人仔細看看。

 

我個人感覺，CodeReview中，第一個不要乾的事是“和測試搶飯碗。”

用CodeReview來檢測準系統的實現是否正確這一行為本身不能講完全錯誤，但至少是低效的。

從產品角度看，CodeReview應該和其它手段形成一定互補，而非是儘可能的重疊。

 

第二個不要乾的事情是和“和靜態測試搶飯碗”。

但凡可以依賴靜態測試得出的結論的事情，在CodeReview中應該被忽略，比如：函數複雜度等。

 

這樣CodeReview中應該乾的事就變的清楚些了。

•  測試很難覆蓋的地區，如：多線程同步，極端條件的處理等。
•  邏輯是否清晰，如：基本結構和設計的偏差，全域變數的使用是否合適等。
•  靜態測試無法覆蓋的編碼風格。編碼規則中東西儘可能自動分析，但總有些東西無法自動檢查，比如異常使用的是否合適等。

這類東西也只能在CodeReview中覆蓋了。

 

在CodeReview中，我傾向與做減法而不是加法，這樣想的一個關鍵前提就是，項目的時間似乎總是不夠，

這時候就只能讓CodeReview，靜態測試，單元測試這些職能進行互補，而不能讓他們儘可能重疊。