[譯] 代碼評審的 8 點建議

• 原文地址：8 Tips for Great Code Reviews
• 原文做者：Kelly Sutton
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：xiaoxi666
• 校對者：Augustwuli, Raoul1996

若是你想得到本系列博客的最近更新，請加入咱們由幾百個開發者組建的社區，並訂閱個人專欄。

學校有一點沒有教你的是：如何進行代碼評審。你學習了算法、數據結構，以及編程語言基礎，但沒有人坐下來講：「這是一些能讓你提出更好的反饋的辦法」。

代碼評審是編寫良好軟件過程當中的關鍵步驟。代碼評審在於儘量使得其具有高質量且 bug 少的特色。良好的代碼評審文化也會帶來其餘收益：你減小了產生 bug 的因素；同時代碼評審也是培養新成員和分享知識的良好途徑。

假設

閱讀本文以前，有必要做出幾點假設，以下：

• 你在一個受信任的環境中工做，或者你和你的團隊正在改善你的信任度。
• 你能夠在非代碼環境中提出反饋，也能夠在你的團隊中提出反饋。
• 你的團隊但願產出更好的代碼，也理解 perfect 是一個動詞而非形容詞。咱們可能會爲明天的工做找到更好的解決方案，同時咱們須要保持開放的心態。
• 你的公司注重代碼的質量，而且理解高質量代碼或許沒法快速「上線」。這裏引用「上線」是爲了說明：不少時候未經測試和評審的代碼實際上可能不起做用。

有了上述假設條件，接下來讓咱們進入正文。

1. 咱們是人類

要知道其餘人在你將要評審的代碼中投入了不少時間，他們也想讓代碼質量更高。你的同事（經過代碼）努力地表達本身的意圖，誰也不想寫出蹩腳的代碼。

保持客觀是很困難的。請確保老是評判代碼自己，並試着去理解上下文的含義。儘量減輕評判帶來的不良影響。不要說：

你寫的這個方法使人費解。

嘗試換個說法以針對代碼自己，並增長你的解釋：

這個方法有點很差理解，咱們是否能夠爲這個變量起一個更好的名字呢？

這個例子中解釋了咱們做爲讀者時對代碼的感受，這關乎於咱們本身以及咱們對代碼的解釋，而與編寫者的編碼方式或意圖無關。

每一個的 Pull Request 都有它自己的高難度交流。嘗試與你的隊友達成共識, 共同努力以實現更好的代碼。

若是你剛剛認識一名團隊成員，而且針對某個 Pull Request 有一些重要反饋，請共同瀏覽一遍代碼。這將是發展同事關係的一個好機會。以這種方式與每一個同事合做，直到你再也不感到難爲情。

2. 自動檢查

若是計算機能夠決定並執行一條規則的話，那就讓計算機完成它。爭論應使用空格仍是 tabs 屬於浪費時間。相反，應把時間花在制定規則上而且達成一致。這也是觀察團隊如何在低風險情景下處理「反對仍是提交代碼」的機會。

編程語言和現代工具流不缺少執行規則（的輔助檢查程序）並反覆應用它們的方法。在 Ruby 中，有 Rubocop；在JavaScript中，有 eslint。找到語言這類輔助檢查程序，並將其嵌入到構建流中。

若是你發現現有的輔助檢查程序存在不足，那麼能夠本身編寫！定製規則至關簡單。在 Gusto 中，咱們使用定製的輔助檢查規則來捕獲類的廢棄用法，或者適當地提醒人們遵照某些 Sidekiq 最佳實踐。

3. 全員評審

聽起來，把所有的代碼評審工做交給 Shirley 是一個好主意。

Shieley 是一位大牛，她老是知道如何有效編程。她清楚系統的輸入輸出，在公司呆的時間比團隊成員的總和都要長。

然而對於某些事情，Shirley 理解它並不表明其餘團隊成員也理解了。評審 Shirley 的代碼時，年輕的團隊成員或許會在指出某些問題時猶豫不決。

我意識到將評審工做分配給不一樣的成員會產生有益的的團隊動力和更好的代碼。一名初級工程師在某次代碼評審中做出的最有力的評論是：「我看不太懂。」這是使代碼變得更加清晰簡單的機會。

在團隊中推廣代碼評審。

4. 保持可讀性

在 Gusto 中，咱們使用 GitHub 管理咱們的項目。GitHub 中的每一個 <textarea> 都支持 Markdown，這是一種在註釋中添加 HTML 格式文本的簡單方法。

使用 MarkDown 是一種增長內容易讀性的方式。GitHub 及你選用的工具可能會具有語法高亮功能，這對代碼片斷的閱讀很是友好。使用一對反引號 (`) 嵌入代碼或三個反引號 (```) 增長代碼塊，帶來更好的交流體驗。

善於利用 Markdown 語法（尤爲當你寫的代碼包含註釋時）。這樣作將有助於使你的評論內容具體且重點突出。

5. 至少反饋一條正面評價

代碼評審本質上是帶有消極影響的事情。在我把代碼發到網上前，能夠告訴我這個代碼有什麼問題。這就是代碼評審應該乾的事情。開發者投入時間編寫代碼，同時但願你能指出如何可以作得更好。

爲此，老是應該給出至少一條正面評價，而且使其富有意義和充滿人情味兒。若是有人最終解決了長期攻關的問題，請無保留地表露出興奮，它能夠是簡單的一個 👍 或者 「贊一個」。

在每次的代碼評審中留下正面評價會微妙地提醒咱們在一塊兒共事。若是咱們生產良好的代碼，咱們都將受益。

6. 提供替代方案

我嘗試去作的一件事是：用替代方案來實現（相同的功能），尤爲是剛剛開始學習一種編程語言和框架的時候。

謹慎一些。若是表述不恰當，可能會讓人以爲你傲慢或自私：「這是我實現的方式。」儘可能保持客觀，並討論你所提供的備選方案的優缺點。若是你的方案很棒，將有助於拓展每一個成員的技術視野。

7. 延遲是關鍵因素

快速修正代碼很是重要。（下面的規則會使它變得更容易：保持小代碼量。）

長時間地延遲代碼評審會下降生產力和鬥志。被分配去評審 3 天前的 PR 會讓人感到不舒服。噢，的確如此。我究竟在幹什麼？反覆地在上下文構建環境中切換。要糾正這一點，你須要提醒你的團隊，進度依賴於整個團隊而非我的。促使你的團隊關注代碼審查的延遲狀況，並把它作得更好。

若是你但願減小本身的代碼評審延遲，我建議遵循這條規則：編寫任何新代碼以前，首先評審代碼。

做爲一種直接處理延遲的策略，嘗試在代碼評審時進行配對。找一個結對編程工做臺，或者共享屏幕來瀏覽和評審代碼。生成解決方案時採用配對方式，使你們都同意它。

8. 對提 pr 者的忠告：保持小代碼量

在一次代碼評審中，你收到的反饋的質量與 Pull Request 的代碼量成反比。

爲做出使人信服且有建設性的反饋，要知道更小的 Pull Request 更易於閱讀。

若是你保持 Pull Request 足夠小（避免 The Teeth）（譯註：原文中用牙齒的大小類比代碼塊的大小，若是牙齒太大則可能會戳破皮膚，同理，代碼塊也不宜太大），你將須要結合上下文進行更大範圍的交流。這個 Pull Request 如何合入本週本月的工做中？咱們下一步要作什麼，以及這個 Pull Request 是怎麼推動工做的？諸如白板編程和麪對面討論這些形式的討論很是重要。更小的 Pull Request 很難讓人記住它的上下文。

不一樣的編程語言和團隊對「小」有不一樣的定義。對我而言，我儘可能保持 Pull Request 少於 300 行代碼。

結論

但願這 8 條建議可以幫助你和你的團隊做出更好的代碼評審。經過改進大家的代碼評審流程，你能夠收穫更好的代碼、更融洽的隊員，以及更好的業務發展。

你的團隊在實施代碼評審的過程當中使用到了哪些方法？歡迎到個人 Twitter 上留言。

---

須要更多博客資料？請查看系列 Feedback for Engineers。

特別感謝 Omar Skalli、Justin Duke 和 Emily Field 在本文成稿過程當中給予的反饋。

若是你想得到本系列博客的最近更新，請參與由數百人組成的開發者社區，並訂閱個人專欄。

若是發現譯文存在錯誤或其餘須要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。