做了一百萬次代碼評審，我們總結了這些血淚經驗

作者丨Szczepan Faber

譯者丨無明

策劃丨小智

LinkedIn 的每個團隊都使用同樣的代碼評審工具和流程，任何一個工程師都可以評審別人的代碼，甚至可以為其他團隊貢獻代碼。

LinkedIn 是全球知名的職業社交網站，在全球範圍內有數億用戶。該公司的工程技術團隊實力同樣強勁，最出名的就是開源了 Kafka 等一系列流行技術。

此前，LinkedIn 的代碼評審總量達到了里程碑式的一百萬次。為此，LinkedIn 社交網絡服務工具部門負責人分享了一路下來他總結的代碼評審經驗和教訓。

閱讀和評審代碼是工程師每天都要做的事情。但是，這與正式的代碼評審流程有所不同，正式的代碼評審要求每一個代碼變更在進入生產環境之前都要經過其他團隊成員的評審。LinkedIn 從 2011 年開始將代碼評審作為開發流程不可或缺的一部分。我們的代碼評審目標是盡可能順暢地在快速增長的團隊中進行。好的代碼評審（有意義且有用的評審注釋）有助於提升整個公司的水準。在 LinkedIn，代碼評審是質量保證和知識分享的一部分，並讓整個工程文化朝著更好的方向發展。

在公司層面實現代碼評審最大的一個好處是可以提高開發流程標準化水準。LinkedIn 的每個團隊都使用同樣的代碼評審工具和流程，任何一個工程師都可以評審別人的代碼，甚至可以為其他團隊貢獻代碼。這也解決了諸如“我可以修複他們的 bug，但我不知道該怎麽構建和提交”之類的問題，促進了各個技術部門之間的協作。

將代碼評審作為開發流程不可或缺的一部分有助於形成一種健康的反饋文化：工程師樂於在工作的各個領域提供或接受反饋，而不僅僅是在代碼層面，因為反饋已經成了日常工作的組成部分。在我們看來，提供和接受反饋都是很好的成長機會。事實上，高質量的代碼評審是 LinkedIn 員工晉升的一個重要參考因素，因為它為工程師的技術能力提供了有力的證明。

在過去幾年，我們總結出了一些最佳實踐和技巧。下面以問答的形式提供了一些指南，幫助代碼評審人員和被評審人員“榨乾”代碼評審的最後一滴油水。

1

我真的了解“為什麽”代碼要這麽寫嗎？

為了促成最好的代碼評審，每一個代碼提交都應該包含設計概要，大致解釋一下做出代碼變更的動機是什麽。如果只能從代碼中推敲出代碼變更背後的緣由，是很難實現高質量的代碼評審的。代碼提交者應該主動提供變更說明，把它們包含在提交日誌裡，這樣也有助於提高代碼文檔的質量。

2

我提供了正向的反饋嗎？

在一個到處都是聰明人的公司，獲得乾淨的代碼和整潔的測試覆蓋率是理所應當的。正因為如此，代碼評審一般都隻關注代碼中出現的問題。但問題是，大部分人需要從正向反饋中獲得參與感和鼓舞，即使是工程師也不例外。如果評審人員發現代碼中有值得稱道的地方，就要把它們指出來，並給以正向的反饋。這樣有助於提升團隊士氣，而且正向的反饋通常具有感染力。對於代碼評審注釋，任何正向的反饋都應該是明確的，如果認為代碼寫得好，就要說清楚好在哪裡。

3

我的代碼評審注釋夠清楚嗎？

不管是正面的還是負面的反饋，每一個注釋都應該能夠清楚地表達評審人員的想法。面對太過簡陋的評審注釋，代碼提交者根本無法領會評審人員的意圖，儘管這些東西對於評審人員來說是顯而易見的。如果有疑問，過度解釋總比簡陋的反饋要好得多，因為簡陋的反饋會導致更多的問題，需要來回溝通，浪費時間。評審人員可以在注釋裡寫上“減少重複”、“提升覆蓋率”或者“讓代碼更容易測試”，等等。這樣做除了可以讓評審人員的注釋更清晰明了，也有助於讓團隊達到更高的設計水準。

4

我是否認可代碼提交者所付出的努力？

我們應該認可努力工作的人，不管其產出的成果是什麽，這樣有助於培養高士氣的團隊。有些代碼質量不高，需要反覆修改。對於這類情況，我們應該肯定代碼提交者的努力工作，即使他們需要返工。最好的方式是在高質量的評審注釋中加入適當的解釋，認可好的想法（提交的代碼中總有好的方面），並使用禮貌用語，比如“謝謝”。

5

這是個有用的評審注釋嗎？

通過問自己這個問題，可以很容易地知道一個評審注釋是否是必要的。對於工程師來說，代碼評審應該是有用的開發工具，而不是無用的負擔。如果你覺得某個評審注釋不是必需的，就把它刪掉。比如，代碼格式問題就不是一個必需的評審注釋。代碼風格和格式這類事情應該讓自動化工具來做，工程師不應該關注這些問題。

6

“測試完畢”裡的內容夠詳盡嗎？

在 LinkedIn，每一個提交的代碼變更都必須包含“測試完畢”部分。以 GitHub 為例，開發者在提交代碼時會把“測試完畢”的內容放在 PR 描述裡。“測試完畢”應該包含哪些信息？這取決於代碼變更的重要程度和測試覆蓋率。如果變更引入新的或者修改過的條件性複雜度，就有必要進行單元測試。在集成測試覆蓋率不高的情況下，有些變更需要進行手動測試。對於這類情況，“測試完畢”部分應該包含測試場景描述和測試結果。如果代碼變更會導致程序的輸出發生變化，“測試完畢”部分需要包含新的測試結果。

7

我是不是太“學究”了？

有些代碼評審注釋裡包含了太多信息，以至於一些不是很重要的建議把重要的問題——真正需要修複的問題——給“埋沒”掉了。太癡迷於摳細節容易拖慢評審速度，還會挑起評審人員和代碼提交者之間的矛盾。清晰的評審期望和積極正向的代碼評審文化有助於避免出現拖遝冗長的評審。

8

總結

總的來說，正式的代碼評審流程有助於提升代碼質量，促進團隊互相學習和知識共享。如果每個團隊成員都能夠意識到兩件事情，他們的工作質量都將得到提升：既然我的代碼需要經過評審，那就好好寫。評審中反饋的每一個問題我都要解決，所以，為了以後不浪費時間，從一開始就要把代碼寫好。當代碼評審成為一種習慣，整個團隊都會很自覺地提供或接受反饋，這是成長和進步的關鍵。

我們從 LinkedIn 過去的一百萬次代碼評審中學到了很多，並希望從下一個一百萬次評審中學到更多。在代碼評審上投入越多，獲得的代碼評審效果就越好，提交的代碼質量也越高，最終產品的質量也更高。高質量的代碼評審是會“傳染”的！