Code Review如何有效的進行？我們一起來看看

　　什么是Code Review?

　　Code Review代碼評審是指在軟件開發過程中，通過對源代碼進行系統性檢查的過程。通常的目的是查找各種缺陷，包括代碼缺陷、功能實現問題、編碼合理性、性能優化等;保證軟件總體質量和提高開發者自身水平。 Code Review是輕量級代碼評審，相對于正式代碼評審，輕量級代碼評審所需要的各種成本要明顯低得多，如果流程正確，它可以起到更加積極的效果。正因如此，輕量級代碼評審經常性地被引入到軟件開發過程中。

　　為什么Code Review?

　　1.提高代碼質量。

　　2.及早發現潛在缺陷，降低修改/彌補缺陷的成本。

　　3.促進團隊內部知識共享，提高團隊整體水平。

　　4.評審過程對于評審人員來說，也是一種思路重構的過程。幫助更多的人理解系統。

　　5.是一個傳遞知識的手段，可以讓其它并不熟悉代碼的人知道作者的意圖和想法，從而可以在以后輕松維護代碼。

　　6.鼓勵程序員們相互學習對方的長處和優點。

　　7.可以被用來確認自己的設計和實現是一個清楚和簡單的。

　　如何做Code Review?

　　Code Review檢查什么?

　　1.結構問題

　　代碼比較大的問題，不是一兩個地方有技術缺陷，也不是業務邏輯錯誤，而是整個軟件設計的不好。前兩者更容易通過測試或使用來發現和更正，但后者就不同了。如果回想一下自己見過的各種爛攤子，是不是有同感?具體哪里有問題怎么改說不上來，就是整個軟件看上去混亂無章，無從下手。

　　具體結構問題包括：重復拷貝代碼(不封裝函數，不用Template/泛型……)，函數過長(超過一屏幕就叫過長)，錯誤封裝(不恰當的public/不用Interface/不內聚/強耦合/在類中封裝了無關方法……)，內容錯誤(多個無關類置于一個文件/不恰當的命名……)等等。

　　改正結構問題，是從編寫可靠軟件向編寫精美軟件邁進的重要方法。

　　2.業務邏輯問題

　　就是軟件是否與需求的要求符合的問題。審核者和被審核者經常對業務需求的理解有差異，借此機會同步一下，必要時引入PO(產品經理/產品負責人)。

　　有人會說業務邏輯問題不是一測試就知道了嗎?可是測試一般發生在很久以后，有些邏輯測試還需要一定的觸發條件，而且測試只會發現失效(failure, 與預期不符)而不能發現缺陷(defect, 具體哪里出了錯)，等積累長了，誰也找不到原因了。

　　3.編程素養問題

　　很多問題屬于那種“這樣也行那樣也行”的狀態，比如命名/初始值/縮進/斷行……但是高手的做法總是比新手好一些。

　　比如bool result = true; 這句話就有問題，剛初始化就先宣布成功，必有隱患。這是一個真實案例，而下面也的確有一個分支錯誤地返回了這個true(實際案例是個HRESULT)。而發現這個問題，不是測試而是代碼檢查。實際上測試幾乎發現不了這些問題，比如上面那段代碼會在某文件打不開的時候錯誤地返回這個true，而在測試中幾乎不會故事破壞那個文件來測試其結果。

　　經常進行Code Review

　　常見的Code Review是高手審核新手，或者師傅走查徒弟。一般而言，大致高手每天能編寫100多行有效代碼(按分號計數)，新手會多一些但也不超過200(他們編寫代碼比較費)，也就是10個屏幕以內。有經驗的人一定知道：高手看新手的代碼，5秒鐘就能發現問題。所以不用花上很長時間去做Code Review，而應該“少吃多餐”，每次可以5分鐘，10分鐘，每天2-3次甚至更多。看到一個問題就要徹底解決，不需要一次檢查很多，問題一次比一次少即可。

　　但是切記不可積累，隔很長時間才去做Code Review，你就會面臨那近萬行的代碼，以前N多摻和在一起的功能，你會發現，整個Code Review變得非常地艱難，用不了一會兒，你就會發現你會疲憊地打著哈欠，但還是要堅持，有時候，這樣的Review會持續N個小時以上，相當的夸張。而且會出現相當多的問題和爭論，因為，這就好像，人家都把整個房子蓋好了，大家Review時這挑一點那挑一點，有時候觸動地基或是承重墻體，需要大動手術，讓人返工，這當然會讓蓋房的人一下就跳起來極力地維護自己的代碼，最后還傷了他人的感情。

　　我們怎么做 Code Review

　　我帶過的項目中，做Code Review這方面大多感覺比較凌亂，也沒有什么統一的做法。不過從形式上來看大體可以分為兩大類：一類是TM技術經理對項目中成員Team一個一個的做Code Review，或者是團隊資深人員來做(姑且就叫個人式吧)。一類是做Code Review Meeting，以會議形式來做Code Review(姑且叫會議式)。

　　1.個人式

　　對于個人式，其實在上面“如何做Code Review”的話題中已經談到了很多了。包括我們要及時的不定期的每時每刻的去做Code Review，包括我們要按照結構問題，業務邏輯問題，編程素養問題逐一去檢查Code等等。很多項目我們也都做了，甚至是都做到了。只是還有不夠好的地方，需要深入的地方。具體的方法上面已經講了，后面我會具體講講如何量化和跟蹤。而對于PM來說，如何監控Code Review這件事就顯得非常重要。

　　2.會議式

　　會議式，真正的會議式去做代碼評審，如果做到位了效果應該是較好的，最理想的情況是一堆專家(包括技術專家甚至還有業務專家、測試專家等)，拿著代碼一行一行的去Review。但是這種做法的成本也非常之高，不管是時間成本也好，還是費用成本都相當的昂貴，一般只有在大型尖端項目才會使用，比如航天航空的項目，做Code Review之后的缺陷率是相當的低的。我們是怎么做Code Review Meeting的呢?首先我們會在開會之前，選出典型的案例或者問題一起拿到會上去討論，多半是分享一些經驗和強調一些容易犯錯的地方。一般一次會議不會超過2個小時，每周一次會議即可。這樣會議的效果比較好，成本也相對較低。因為由于Team中成員的“素質”參差不齊，所以一起去做代碼評審確實效果很差。

　　我對 Code Review 的一點思考

　　作為PM我，對Code Review的思考是，我應該如何管理好Code Review?也就是說假設我把Code Review當做一個項目來看，怎樣做好這個項目呢?

　　其實很簡單，首先我要有一個正確的、真實的、可執行的計劃，然后能在實施Code Review時給予TM或評審人一定的指導，再然后跟蹤偏差，分析原因，變更計劃。

　　那如何做?而且要是正確的、真實的、可執行的。這里我們需要結合一下Project Quality Plan了。可能有的童鞋還不知道，我簡單解釋一下Project Quality Plan，Project Quality Plan是一個項目質量計劃，主要內容有項目交付物以及交付要求，計劃達到怎么樣的質量目標，要采取怎么樣的過程方法，Quality Breakdown各個階段的質量目標分解等等。通過詳細的質量目標分解我們就可以預測各個階段預計產生的缺陷數是多少。此時我們PM就要思考，有了各個階段的缺陷數量，我們是不是可以分解一下，那么我們做Code Review的目標是要發現多少缺陷呢?舉個例子：假設我們代碼的規模是100k行，我們目前團隊產生缺陷數的基線大概是12~15 (Bugs/Kloc)，Code Review需要找出8~10 (Bugs/Kloc)，也就是100*8~10=800~1000。這樣一來我們總數就有了，也就是說對于100k代碼行這種規模的項目我們Code Review總共要找到800~1000個缺陷才算達到了比較好的效果。當然如果做到這里還遠遠不夠，我們還要對這個目標進行細化的分解。要分解到模塊，分解到人(如果多人Review的話)。分解到模塊很好理解，我們把整個系統分解為幾個大的模塊，或者模塊集(相關性大的可以放一起)。然后分析模塊的難易度，以及模塊將來可能的負責人，然后評估每類模塊我們應該找到多少缺陷。可能對于業務復雜或者算法復雜或者負責人水平較低的模塊我們需要更多的時間去Review并產出更多的缺陷，反之則少。如下圖：

模塊 規模 復雜度 PIC 缺陷分布 （計算） （調整系數） 1 20k 高 中 240~288 20*12 1.2 2 20k 中 中 180 20*9 1 3 20k 中 中 180 20*9 1 4 20k 中 弱 180~198 20*9 1.1 5 20k 低 弱 120 20*6 1

　　有了具體的計劃Code Review的時候也就有了指導和參考目標。在執行的時候我們也就可以規劃出人合理的力投入分配。做起來相對來說就比較容易了。

　　最后就是跟蹤、偏差分析與變更了，當發現我們與實際計劃又嚴重偏差我們要分析原因，然后做計劃變更。比如發現偏差時，我們可以用根因分析，人、機、料、法、環、測。我們哪里做的不夠好，如果可以解決，找出主要原因立刻解決即可。如果發現是計劃有問題就去變更計劃好了。這里就不討論具體方法了。方法有很多，只要適合自己的項目即可。

　　其實Code Review的方法還有很多，比如結對編程也是一種很好的形式，特別適合敏捷XP團隊，但是因為目前我也沒有很好的實踐，所以也就沒有寫到。