最近被要求做一個關于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的結果，并且堅持開展這個活動。這才是最重要的