代碼評審的不可能三角

Code Review 是保證代碼質量的重要手段之一，但許多研發團隊中它經常因爲各類緣由並未獲得真正的落地。爲何會這樣呢？本文但願用一個很是簡單的觀點來理解這個現象，並據此給出一點優化的想法。

觀點

咱們的觀點能夠用一句話歸納，那就是代碼評審很是難同時知足高覆蓋率、強約束力和低開銷這三個條件。這三個條件分別有什麼含義呢？

• 高覆蓋率，意味着評審須要覆蓋項目中幾乎全部的提交，而不是隻評審新人的代碼或者是批改暑假做業般的隨機「抽查」。
• 強約束力，意味着在保證評審自己質量的基礎上，評審中指出的問題都須要獲得切實的解決，不然不該合併代碼或發佈正式版本。
• 低開銷 (overhead)，意味着評審不該佔用過多寶貴的開發時間，更不該像某些會議那樣提起來就讓人皺眉頭。

論證

知足上述三個條件的代碼評審，應該是每一位對代碼質量有追求的開發同窗都不會排斥的。但爲何咱們認爲這樣的評審可行性不高呢？簡單地組合一下上述的條件，就不難發現矛盾了。

• 同時知足高覆蓋率和強約束力的評審，時間是不可控的：爲一些強調代碼質量的開源項目貢獻過 non-trivial 代碼的同窗，應該都知道即使是一個簡單的 fix，其 PR 均可能由於實現手法和維護者的理解有誤差而長期保持在 Open 狀態（俗稱合不進去），更別說全新的特性與 API 了。
• 同時知足高覆蓋率和低開銷的評審，很容易流於形式：若是制度上約定必須對所有代碼作評審，又不能耽誤版本進度，那麼這時候只要時間稍微一緊，評審就會變成平常回復 LGTM (Look Good To Me) 的走過場了。
• 同時知足強約束力和低開銷的評審，很難覆蓋到所有的代碼庫：一個版本中一般會有一些全新的特性。若是評審者並未參與這個新特性的開發，那麼全量評審一個新特性的上千行代碼，其難度跟打開一個沒有讀過的開源項目並立刻指出其中的 bug 差很少。

折中

若是上述三者不可得兼，咱們應該如何權衡呢？在目前的大環境下，多數軟件項目快速迭代的性質與咱們對「早點下班」的渴望，使得低開銷這一條件一般很難被犧牲。那麼在覆蓋率和約束力之間該如何取捨呢？讓咱們回到「代碼評審有什麼做用」這個話題上吧。咱們知道代碼評審能夠：

• 減小代碼中的暗坑
• 提升被評審者的代碼質量
• 讓團隊成員熟悉代碼

若是評審自己就形同虛設，上面這些好處天然也只是空談而已。所以，咱們仍然很難放棄對約束力的要求。那麼，如何改善這時覆蓋率的問題呢？這裏給出兩點不成熟的想法供參考。

首先，來自 Google Subversion 團隊的經驗能夠給咱們一些啓發：他們將代碼評審與即時通訊、會議、文檔一塊兒，視做團隊中的溝通方式，而不是流程。這樣，溝通方式之間就能夠取長補短地提升團隊效率。實際上，在評審全新特性時「讀不過來」的問題，就能夠經過設計階段的文檔來緩解：文檔與評審一樣是一對多的溝通，而且對文檔中方案的討論顯然比直接討論細節要更容易。一個須要 2 周時間左右開發出的全新特性，按照 問題定義 → 基本思路 → 實現概述 → 改進優化 的結構化方式編寫的文檔，其長度應該僅在千字左右，編寫文檔所需時間與開發時間應當不在一個量級，還可以節約在缺失文檔時向其餘同窗當面溝通該特性的時間（固然，對那種順手就能搞定的需求也要求文檔化，就有些繁冗了）。

另外，代碼評審的覆蓋率問題，還能夠經過必定的提交約定來優化。在筆者翻譯的 conventional-commits 規範中，每一次提交均可以經過形如 fix / feat / chore / refactor 的不一樣類型來作區分，來達成細粒度的可讀提交歷史。那麼，在評審的 Pull Request / Merge Request 粒度上，爲何不能一樣地應用該規範呢？若是咱們按照這種方式區分了 PR 類型，這裏就有很多的想象空間：

• 能夠首先將評審的資源集中在 refactor 與 perf 一類 PR 的評審上。
• 對於 feat 類型存在大量新代碼的 PR，只需其提供了確保團隊成員理解的文檔，那麼就只須要保證方案設計可接受，作保證代碼風格、命名、路徑等隱式約定一致級別的評審便可。
• 咱們能夠選擇性忽略測試階段可能數量衆多的常規 fix 類 PR，但對版本發佈後補充的 hotfix 類 PR，仍然須要評審。
• 對不影響代碼質量的 chore 與 doc 類 PR 能夠忽略評審。

總之，代碼評審是一種溝通方式，但願它可以成爲團隊平常開發「文化」的一部分，而非束縛效率的死板流程。但願本文的想法對一樣被評審困擾的同窗有幫助 :)

P.S. 咱們 base 廈門的前端工具（編輯器）團隊缺人中，有意戳這裏瞭解詳情哈。