高效code review指南

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

我們團隊的code review實踐也并不是一帆風順，兩年前剛開始的時候，形式很粗糙，就是一堆人對着代碼品頭論足。導緻的結果要麼是陷入争論，reviewer說這裡寫得不好，author（本文中用author這個單詞來指代被評審者）辯論說其實沒問題；要麼隻關注一些無傷大雅的細節，發現不了更為嚴重的問題（比如設計的問題）。試了幾次，逐漸感覺流于形式，後來也就不了了之了。

如果發現一個廣為推薦的工具不太好用，那麼除了懷疑這個工具适不适合之外，更應該想想使用姿勢是否正确。于是花了些實踐來學習code review的知識，并與其他團隊交流，在實踐中逐漸形成了一套行之有效的方法。本文記錄對code review的一些認識與思考

本文位址：https://www.cnblogs.com/xybaby/p/12601471.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确實是有價值的，有所收獲才願意持續付出。

本文版權歸作者xybaby（博文位址：http://www.cnblogs.com/xybaby/）所有，歡迎轉載和商用，請在文章頁面明顯位置給出原文連結并保留此段聲明，否則保留追究法律責任的權利，其他事項，可留言咨詢。