研發過程之程式碼檢閱

     在研發過程中，為了保證代碼品質，很多團隊都會使用程式碼檢閱，或者叫做代碼Review。一般情況下，代碼Review都會採用集體Review的形式。

   集體Review

   形式： 一個團隊，大家坐在一間會議室裡面。一人進行講解自己的業務和代碼實現，團隊的其他成員進行Review，提出問題，發現問題和補充不足。

   這樣可以達到以下的目的：

   1.Linus定律 "只要有足夠多的眼睛，就可讓所有問題浮現"。每個人思考和理解事情的角度不同，這樣發現問題也不盡相同，人數越多，發現問題也就越全面。

   2.在進行補充和提出建議的過程中，可以達到組內的開發規範和標準的傳播，使大家明白統一標準。

   3.在講解的過程中，和大家提出問題，發現問題的過程中，可以達到經驗和知識的共用。

   缺陷：耗時過長，在開發時間較短的時候，會造成時間壓力過大。雖然能減少後期成本，但是對於當時來說，短期的壓力。

 

   因為集體Review耗時過長，往往會耽誤大家時間，特別是項目時間緊張的時候，項目負責人往往頂不住壓力，選擇不Review，或者選擇自己一個人進行Review，把問題發給大家。

   負責人Review

   形式：項目負責人進行checkout所有代碼，進行逐個Review，把發現的問題email或者當面告知相關人員。

   這樣可以達到以下的效果：

   1.避免員工設計或者代碼出現問題。

   2.可以達到項目負責人的開發規範和標準的傳播，使大家瞭解其標準。

   缺陷：對項目負責人要求較高，並且耗用其精力過多，使其無法處理更多關鍵的事項。同時因為一個人進行Review，無法對問題進行全面細緻的分析，容易遺漏問題。

 

    後來借鑒了結對程式設計的思想，把結對程式設計改為了結對Review，取得了一定的效果。

    結對Review

    形式：項目群組成員進行結對，兩人一組，互相Review對方的代碼。每次進行輪換Review的對象。

    這種形式，中和了負責人Review和集體Review的優點，但是同時也中和了上面兩個的缺點，達到的是一種均衡。

     效果如下：

           1）兩個人互相Review的時候，可以達到這二人業務和經驗交流。

           2）Review的過程中可以發現bug，並且在講的過程中，講述人也可以發現自身的bug。

           3）加快Review進度，相對於集體Review來說，可以大幅提高Review效率，同時保證一定的效果。

           4）可以達到組織知識的充分共用，組內的人會和每個人進行結對Review，可以全面傳播組內人員的經驗和知識。

       缺陷：1）如果兩人經驗都不足的話，技術交流的效果不明顯。但可以通過和另外一人的交流時得到補充。所以建議最開始的時候，指定結對Review人員，一名經驗豐富者帶一名經驗較低人員。

                 2）缺少足夠多的眼睛，有些bug會被遺漏。

                 3）需要Review的雙方都要有責任心，如果任何一方不負責的話，都會產生問題遺漏。

 

      上面三種Review各有其優點和缺點，建議項目上根據自己的情況進行選擇，或者組合使用。現在建議的方式是每周1~2次結對Review，每2周一次集體Review，研發負責人根據情況進行抽查Review，或者在項目初期和後期進行加強Review。