高效code review指南

大多數程序員都知道而且相信code review（代碼審查）的重要性，但並必定都能很好的執行這一過程，作好code review也須要遵循必定的原則、流程和規範。

咱們團隊的code review實踐也並非一路順風，兩年前剛開始的時候，形式很粗糙，就是一堆人對着代碼品頭論足。致使的結果要麼是陷入爭論，reviewer說這裏寫得很差，author（本文中用author這個單詞來指代被評審者）辯論說其實沒問題；要麼只關注一些無傷大雅的細節，發現不了更爲嚴重的問題（好比設計的問題）。試了幾回，逐漸感受流於形式，後來也就不了了之了。

若是發現一個廣爲推薦的工具不太好用，那麼除了懷疑這個工具適不適合以外，更應該想一想使用姿式是否正確。因而花了些實踐來學習code review的知識，並與其餘團隊交流，在實踐中逐漸造成了一套行之有效的方法。本文記錄對code review的一些認識與思考

本文地址：http://www.javashuo.com/article/p-vvvitypt-ku.html

code review的出發點

咱們從一個需求開發的完整生命週期來看，大約會包含如下過程：

• 需求分析，考慮人員狀況、功能預期上線時間、技術難度等諸多因素，與PM討論合理調整需求，分配資源；
• 總體設計，對設計進行review；
• 代碼開發；
• 開發自我review，觀察、思考與總體設計的出入，保證代碼遵循團隊規範（至少得經過靜態代碼檢查）；
• 添加相應的單元測試，並保證已有的單元測試不受影響；
• code review，請相關同事對代碼進行review，修復review中發現的問題；
• 提交代碼給QA測試，QA會進行功能測試、集成測試、性能測試、壓力測試等；
• 修復測試發現的bug後功能上限。

從上屬流程能夠看出，代碼寫完了會有專業的測試同事來進行全方位的測試，那麼爲何還要code review呢？其次，合格的程序員理論上都會review本身的代碼，還有沒有必要請同事來review呢？

一個bug，可能在代碼review的時候被發現；也可能在測試的時候被發現；最壞的狀況下，被用戶發現，固然，此時極可能給用戶、產品帶來損失。越早發現問題，受影響的人員越少，修復成本就越小。想一想前幾天淘寶的彈窗bug，若是能經過review發現，能拯救多少人的績效。

開發人員有時也有一個誤區，以爲本身完成「代碼開發」這一步就萬事大吉了，測試的事情就應交給QA去執行。但不少時候，QA更多從功能角度去驗證代碼，有時候黑箱測試也很難覆蓋到所有狀況，好比異常、安全性問題、版本依賴。何況如今不少公司都逐漸去掉專門的Test，開發得本身測試，但思惟定勢致使很難發現本身的問題，對本身代碼的review也是如此。另外，知道本身的代碼也被人「拿着放大鏡仔細觀察」，天然寫代碼的時候也認真一些。

另外，從上述流程能夠看出：

• 其實應該有兩次定位不一樣的review：對總體設計的review，主要目的是從大方向上保證設計確實能知足需求；其次是code review，保證代碼實現符合設計約束，且編碼沒有明顯的缺陷。
• 用來code review的代碼，應該既知足團隊代碼規範，又基本保證功能的正確。

在咱們的實踐中，對於複雜的系統，會要求現先設計review。而對於簡單的、或者開發比較有把握的功能，則是將設計review與代碼review合併。本文討論的code review其實就是後者：既關注設計，又關注核心代碼。

code review的目標和原則

code review的首要目標是：找出代碼中的缺陷，保證代碼質量。其次，經過review也能相互學習，提升團隊總體水平，並且特別有利於新人快速融入團隊，保持與團隊風格一致。最後，保證每一個核心功能有多個同事瞭解，下降風險。

從其核心目標咱們就能夠看出code review的第一原則：對事不對人。這一點須要reviewer、author達成共識。code review不是批鬥大會，reviewer、author並無高低之分。

對於reviewer而言，參與的首要目的在於協助發現問題，所以

• 儘可能質疑本身而不是對方

我沒有看懂這段代碼的邏輯
而不是
你這段代碼有問題吧

• 指出代碼有問題而不是指責人

這段代碼是否是可能出問題
而不是
你又寫出bug來了

對於author，應當把review看成一次學習成長的機會 -- 畢竟平時又有誰來給你免費建議和指導呢？所以，不要一開始就是防護的姿態，即便reviewer有所誤解也不用臉紅脖子粗的去爭論。

要真正讓author放鬆，達到和諧review的效果，我的以爲還要注意如下幾點：

• review不該該與任何KPI掛鉤，review發現的缺陷不該歸入績效考覈。
• 團隊Leader應該少發言（不然就會變成Leader說啥就是啥），甚至要少參加無關的review，畢竟任何人都不但願給Leader留下本身很菜的印象。
• 得須要有人充當仲裁者的角色，化解reviewer與author的衝突。並且，必要的時候維護author。

code review步驟以及注意事項

code review 並不簡單是一堆人一塊兒看代碼，要讓code review的效果最大化，整個流程是須要認真組織的：

review前

• author得保證代碼質量：代碼知足團隊規範且基本測試經過
• author至少提早一天通知參與review會議的同事，提供必要的需求、設計文檔
• reviewer簡單瞭解需求、設計、代碼實現

這裏須要注意的是，與會人員越少越好，無關的同事最好不要參加review。若是與會者對相關的功能不感興趣，那麼就存粹是在浪費時間，這也是不少人不喜歡code review的緣由。

review中

review的過程大約是：

• author大體講解需求和總體設計，而後是核心代碼
• reviewer提出問題，author確認是不是問題
• 對發現的問題進行記錄，分類處理

review中須要注意：

• 控制review的時間，codereview自己就是一個高強度的活動，時間過長你們都很疲憊，效率也會降低，經驗值一個小時左右比較合適。
• 控制review的代碼量，須要你們仔細閱讀的代碼最好也控制在200 - 400邏輯行（這個數值也是the art of unix programming中對模塊代碼量的建議值）
• 須要有支主持人控場，把控時間和進度。和任何高效會議同樣，應該避免發散，儘可能只發現問題，並不深刻討論如何解決問題。
• 記錄發現的問題，以及相應的解決方案：
  • 已有明確修復方案只待執行？
  • 仍是須要修復但解決方法尚須要進一步討論？
  • 仍是在下一次迭代時再修復？

reviewer內容依次是：

• 是否知足功能需求，有沒有多作，有沒有少作，有沒有潛在的bug，
• 是否知足非功能需求。性能（高頻調用的函數、核心算法）？可用性（異常處理是否完善）？可讀性？
• 代碼質量、規範

上面也提到，code review自己是個高強度的活動，所以容易漏掉一些關鍵點點，所以不妨作一個review list，對照這個list去考察代碼。list保證了code review的質量下限，且不影響與會者發揮主觀能動性，發現其餘問題。

此外，也須要避免在沒有明確規範的問題下過多爭執。達到一樣的效果，A方法能夠，B方法也能夠，若是團隊沒有約束用哪一種方法，那麼就不要在code review的時候討論。

review後

review會議結束並不意味這個review這個活動結束，由於還有待解決的問題，所以應該藉助工具跟蹤review發現的問題，指明問題的修復者、問題的驗收人、問題的驗收時間。當一次review所關聯的全部問題都獲得修復以後，review活動纔算結束。

總結

如何才能code review有效且高效，總結如下幾點：

• 會前充分準備，與會人員最少化
• 參考review list，發現問題但不發散去討論解決問題
• 會後跟進問題修復

最重要的事，是經過幾回組織良好的實踐讓你們看到code review確實是有價值的，有所收穫才願意持續付出。