如何做好Code Review：思考、方法和實踐

最近被要求做一個關于Code Review的講演。首先要說明的是，我并不是太擅長開展Code Review的活動。做這個完全是因為答應了别人又不好反悔。不過在做準備的過程中還是有一些感想。

　　關于Code Review我所了解到的行業中最著名的是Bill Gates彙報。這是微軟在軟體開發過程中的一個重要環節，因為Bill Gates親自參加而備受關注，在行業中廣為流傳。

　　Ok，進入正題了。

　　我們面臨的共同問題：

　　1、對于開發周期較長的軟體項目，可維護差的代碼對項目造成了極大的困擾

　　2、結構複雜的，體系不清楚的代碼會導緻新成員或者外部幹系人很難融入。

　　3、軟體項目代碼品質低下，Bug衆多并且有關聯累積效應。

　　以上三個問題是我在以往的Code Review活動中總結出來，可以被影響或者解決的問題。也就是說我的觀點是如果沒有上述問題，或者在目前的軟體産品的規模、開發過程的成熟度還沒有達到一定級别時Code Review是可以不做的。當然優秀的開發人員會做自我審查，這是另外一個問題了。

　　總而言之，我認為開展Code Review活動的前提是

　　1、開發過程和品質控制達到了一定的成熟的。

　　Code Review必然與重構相關聯。如果開發過程中更本就沒有重構這樣的活動，那估計Review出來的結果不太容易得到執行。

　　其次是各種标準和規範的齊備性，沒有規矩是不能成方圓的，如果隻有一個命名規範，那可想而知Review的内容不會太深入，效果是以大打折扣。

　　2、代碼達到一定那個的規模一般來說，功能單一的小型項目的體系結構不會太複雜。不太會出現Bug的累積效應。小型項目完全可以通過daily meeting和Test來保證。

　　Code Review并不是一個随便就可以做，或者做了就有好結果的活動。不過無論如何，一旦條件成熟或者資源充足都應該積極的開展Code Review的活動。因為它除了進行品質控制以外，還是一個團隊成員之間進行溝通和互相學習的好機會。

　　Code Review的内容：

　　1、代碼的規範性

　　　　a、混亂而散漫的命名，例如使用a、b、c這樣的單字母對變量進行無意義的命名

　　　　b、随處可見的magic number或則hard code。軟體中const在所難免，不過這些const應該被集中管理起來。而不是可以随意、随處的出現

　　　　c、缺少注釋，或者注釋不完備甚至錯誤

　　2、代碼的結構問題

　　　　a、巨大的類或者巨大的方法

　　　　b、過于複雜的實作

　　　　c、緊耦合

　　　　d、重複的代碼

　3、其他問題

　　　　a、缺少驗證和異常處理。例如不對資料進行驗證，或者不處理異常又或者捕獲無法處理的異常

　　　　b、對工具和架構的錯誤使用。例如有的ORM架構提供非常友善的運作時延遲加載功能，友善倒是友善，濫用卻會有性能隐憂

　　　　c、缺少可讀性。注釋和命名規範是一個問題，不過過深的調用層次都會影響代碼可讀性。

　　　　d、缺少擴充性。例如在沒有DLR的情況下在業務層使用匿名對象。

　　　　e、缺少安全控制

　　　　f、性能隐患。例如在C#中使用了非托管資源而沒有進行釋放，或者說有過多、過于頻繁的I/O通路

　　4、測試問題

　　　　a、沒有測試或者覆寫度不夠

　　　　b、測試代碼滞後，在更改邏輯後沒有對測試進行同步更新

　　以上是一些通常的Code Review的内容了。當然這裡再強調一點的就是規範的完備性，和開發過程的成熟度。Code Review是一種相對進階軟體開發活動，沒有必要一定要執行。不過一旦實施成功将會有巨大的回報。

　　在實施過程中還有一些心得：

　　1、做好準備。如果對項目很熟的話，應該知道哪些地方會有問題，Code Review是重新審視和從内因上解決這些問題的良機。

　　2、不要考慮業務邏輯。完全專注于代碼的實作，例如算法的效率，抽象的粒度。整個代碼體系結構的平衡性

　　3、虛心學習。不要有針對性

　　4、在原則和現實之間平衡。不可能所有事情都完美，是以有的時候我們堅持原則，有的時候修改規範。

　　5、不要讓自己Review自己的代碼

　　6、總結跟進Review的結果，并且堅持開展這個活動。這才是最重要的

====================================分割線================================