如何高效迅速的進行CodeReview

前言

不少公司都要求項目作CodeReview，但不少人第一次CodeReview每每不知道該如何作，也不知道爲何去作。筆者參加過幾個項目的CodeReview，發現一些共性問題：

• 有時候參與Review的人太多了，意見太分散，Review時間拉的很長，發現問題效率低；
• 有時候會發現一個CodeReview時間很長，參與者會以爲煎熬和浪費時間；
• 有時候不太瞭解對方評審的東西，無法跟上你們的思路，影響效率；
• 有時候走查的代碼量太大了，沒法作到詳細走查；
• 有時候會看到有些人無所事事、精神不集中、不發言，影響效果。

對這些問題，用魚骨圖作個分析：

 

 

但願本文中的一些建議可以緩解上述問題，能使你們更快的瞭解CodeReview的意義和方法，有經驗的人可以更加快速有效的進行CodeReview。

 

CodeReview的目標和原則

CodeReview的目的是提高代碼質量，儘早發現潛在缺陷與BUG，下降修復成本，同時促進團隊內部知識共享，幫助更多人更好地理解系統。

建議CodeReview的原則以下：

• 發現代碼的正確性

代碼審查用意是在代碼提交前找到其中的問題——你要發現的是它的正確性。在代碼審查中最常犯的錯誤—幾乎每一個新手都會犯的錯誤是，審查者根據本身的編程習慣來評判別人的代碼。

• 不只是在Review Code，更是在分享和學習

Code Review最重要的是講解者分享業務流程和設計思路，參與者經過這些講解得到這些信息，使得更多人理解這個系統，提高團隊總體水平，使得團隊維護代碼的能力提高。

• 高效迅速完成CodeReview

咱們不能爲了應付匆匆忙忙的進行一次代碼審查，效率也是很重要的，若是不能保證Code Review目的實現，那麼評審即是徒勞的。

 

如何高效完成CodeReview？

參與者要檢查設計的合理性以及業務邏輯是否錯誤，檢查代碼可讀性；講解者要想辦法分享設計、技術、經驗等知識。

1.檢查設計的合理性和業務邏輯的正確性：

• 代碼的設計是否符合設計要求：
  • 若是存在代碼和設計有出入的地方須要問詢爲何要變更，由於這些變更有多是出於開發者在真正設計代碼時候的深刻考慮，或者是因爲一時大意出現誤差。
• 業務邏輯是否正確：
  • 業務流程是否按照詳細設計的流程走，不要出現本來是先A流程後B流程而設計的時候出現先B後A，或者丟失流程。
  • 某些傳入參數是否合理：判斷某些接口的參數輸入是不是冗餘的，好比輸入A字段能夠知足A接口裏面的全部操做，那麼多輸入一個B就冗餘的。
  • 數據庫字段的設計，數據庫的設計是對實際業務的映射，咱們要保證每個字段的出現都反應實際業務而且通過合理性的驗證，好比設計table1的時候A字段在table2中已經出現，而且A和B表有相應的關聯，那麼要注意A字段對於table1的冗餘是否有合理性，若是沒有合理的說服性能夠去掉A，而節省對A字段的維護成本（存儲空間，更新操做等）。
  • 某些判斷是否合理，好比某些參數的輸入金額是否能夠爲0的判斷等等。
  • 系統交互是否合理，好比在代碼設計的時候沒有關注考慮系統交互的順序而形成有些信息不能獲取到；好比獲取支付方式的費率信息必需要等待支付的時候才能拿到，那麼獲取這些信息就應該放在pay_trans的時候而不是create_trans，大多數這種問題其實都是詳細設計時出現的，代碼評審階段比較少見。
  • 是否有異常處理機制，一個好的代碼設計應該考慮各類異常並對相應的異常作出合理的處理，好比接口的可重入，當代碼檢測到有重入的這種狀況，怎樣去作這種異常處理使得調用方能捕捉的這些異常而進行後面的處理。
• 關注業務可拓展性：
  • 咱們的業務在不斷的發展，每個項目設計都會影響後續業務的拓展，一個好的設計應該考慮到後續業務的發展，而儘可能避免定製化的設計。
• 關注使用到的數據結構、設計模式和代碼性能：
  • 一個好的數據結構和設計模式能夠增長代碼的可維護性安全性和效率等，好比咱們在設計的時候要考慮到不一樣的場景選擇什麼樣的數據結構，有時候咱們會糾結於用map仍是用hash_map，這時候咱們要根據具體的狀況具體分析；
  • 當咱們設計代碼的時候若是能用上系統提供的函數那麼最好不要本身去寫，好比本身實現一個鏈表的時候是否能夠想到用系統庫提供的list_head以確保鏈表結構的正確性；
  • 某些設計若是能套用設計模式會讓設計更加美觀也讓閱讀者更加明瞭；出於對系統性能的考量，咱們要關注編寫代碼對系統的開銷，包括使用的算法是否合理，以及對某些比較耗時的操做好比數據庫的操做要加以關注。

2.檢查代碼可讀性和可維護性：

• 若是代碼的可讀性強，那麼維護起來也就方便不少；一個好的代碼規範和編碼風格會節省你們對代碼的理解時間，減小維護成本；雖然咱們有編程規範檢查工具，但有些內容檢查不出來，是須要靠你們去規範的。
• 關注代碼註釋：咱們在編寫函數和進行邏輯判斷的時候最好要標註一下這個函數或者這段判斷是用來作什麼的；作了這種註釋的好處，一來當別人閱讀這段代碼的時候看到你的註釋之後就會根據你的思路快速理解代碼，甚至不閱讀直接跳過；二來防止本身因爲長時間不閱讀代碼而忘記這段代碼的用途。
• 關注命名規範：雖然咱們有本身的編碼規範，可是這種規範只是限制了使用駝峯命名法仍是其餘命名法；而好的命名風格應該是看到變量或者函數名字就能「望文生義」，畢竟咱們不能把本身寫的全部代碼都作註釋。
• 關注重複代碼：若是出現大量的重複性代碼，要考慮將這些代碼抽象出公用函數，以減小代碼量並加強代碼可讀性。
• 關注繁瑣的邏輯：若是一個簡單的功能卻對應大篇幅的代碼，要考慮一下是否是有比較簡單的實現方式，由於過於複雜的代碼會給後來者的維護帶來麻煩；若是沒有簡略的辦法，必定要把註釋寫好。

3.分享設計、技術、知識和經驗

• 在代碼審查的過程當中，你們每每把關注點放在發現代碼的不足上，忽略了代碼評審過程當中的設計思想、技術方法、業務知識的傳播，我以爲這些內容也是很是重要的，也須要同時關注。
• 評審者在本身的代碼時會深刻業務流程，參與這能夠看到評審代碼的一些算法、數據結構、設計模式甚至是系統架構等知識以及評審者在編碼過程當中踩過的坑；經過這些信息參與者能夠提高本身的業務水平和技術能力使得整個團隊的水平獲得提升。
• 參與者除了要有這種學習意識外，評審者也要想辦法讓參與者更加快速高效的去理解代碼中傳播的知識，這樣能幫助提高Review速度，因此建議評審者能簡單介紹一下項目的背景以及詳細設計，這些信息的介紹有如下好處：
  • 首先，代碼的設計是按照詳細設計來執行的，可是設計者在真正code的時候會出現一些變更，這些變更要給你們一個同步；
  • 其次，參與過詳細設計的人可能因爲沒有直接參與的code，時間長會忘記以前詳細設計的流程，簡單介紹以後就會讓參與者想起，方便參與者的理解；
  • 第三，對於沒參與詳細設計的同窗，在簡單介紹過這些信息後，能夠有個大體瞭解，否則整個評審過程會很煎熬；
  • 因此，若是參與者對代碼的信息不理解，會形成參與者理解代碼的難度，也就不能提出有建設性的意見，同時也難以學到評審中傳播的知識；這一點在以前的評審中是比較容易被你們忽略的，尤爲是在跨團隊代碼評審時，準備不足和經驗不足的同窗是很難理解對方在講什麼的。
• 講解code的時候最好是以接口功能爲單位去講解
  • 若是評審者一會兒把全部的詳細設計都講解完，可能會由於信息量比較大，或者設計到一些細節問題，參與者不能有效的記住或理解也會影響評審的速度和效率；
  • 評審者能夠在講解的過程當中分享一下本身踩過的坑，參與者能夠隨時根據本身發現的問題進行討論。

 

如何迅速完成CodeReview？

所謂的迅速就是節省時間，只要咱們儘可能避免一些意義不大的事情就能節省時間，加快評審速度，要作到這點建議你們儘可能不要作如下這些事情：

1.不要刻意地去尋找代碼bug

• 有些代碼的邏輯是比較複雜的，若是是很容易就發現的缺陷，大多數狀況下評審者本身在編碼過程就會發現，那麼剩下不容易發現的缺陷要發現也會花費較多的時間，這些問題能夠交給測試人員去發現；
• 若是參與者刻意去找bug會形成顧此失彼，忽略更重要的東西；固然，有些bug你可能一眼就看出來了，那提出來就再好不過了。

2.不要按照本身的編程風格去評論別人的代碼

• 有些人蔘與者比較自信，對本身寫得代碼感受很滿意，因此有時候就會根據本身熟悉的編碼語言或者編碼風格去評論別人的代碼；
• 做爲參與者，只要以爲評審者的代碼符合命名要求和設計要求就能夠了，但假如評審者的代碼缺陷很明顯，能夠提出帶你們進行討論。

3.不要帶着抨擊和質疑別人能力的心態去進行代碼評審

• 有時候參與者可能心情很差，或者感受對方是新人就忍不住會抨擊對方的代碼，這樣會比較容易在模棱兩可的問題上浪費時間；
• 參與者可能認爲A方法好，評審者可能認爲B方法也不壞，這樣就會形成沒有必要的爭論而浪費時間。

4.不要在不肯定的問題上爭來爭去

• 你們在討論的時候若是某些問題討論一段時間之後仍然沒有結論，或者須要第三方確認或者評審者不能立刻理解參與者提出的意見時，不要花太多時間討論這些問題；
• 把這些問題先記錄下來，等會議結束後評審者能夠與參與者進行線下討論，同時將這些問題根據本身的理解進行解決，以後給你們一個反饋便可，這樣能夠節省不少時間。

5.不要聽不進別人的意見

• 有些評審者比較執拗，不肯意接受你們的意見，會形成一些沒必要要的爭端和討論，浪費時間；
• 固然，有時候參與者的意見不見得是最好的，做爲評審者將其做爲一個參照的方向和視角，若是存在爭論，這些建議也能夠作成會議記錄，評審者私下和建議提出者討論之後給你們一個結論。

6.參與者最好不要本身都沒想明白就提意見

• 若是參與者本身沒有想明白的事情就去提意見，那麼評審者反問的時候會浪費你們的時間；
• 參與者能夠先將本身的想法大體記下來，本身想清楚了以後再提給評審者也是節省時間的辦法。

7.評審前最好先經過代碼靜態檢查工具檢測

• 通常規範性的問題均可以經過靜態檢測工具發現，藉助工具是最省事，也是效率最高的，還能夠避免你們都評審時提出不少規範性問題，而遺漏了業務邏輯、設計合理性等問題。

寫在最後

但願咱們都可以有效而迅速進行CoderReview，一方面提高代碼質量自己，另外一方面也能夠創造一個良好的學習氛圍互相支持提高團隊的總體代碼水平。

做者：趙客縵胡纓v吳鉤霜雪明 連接：https://www.jianshu.com/p/e9f9aef9a0e9 來源：簡書 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。