[譯] 程式碼評審的 8 點建議

xiaoxi666發表於2018-10-25

如果你想獲得本系列部落格的最近更新，請加入我們由幾百個開發者組建的社群，並訂閱我的專欄。

學校有一點沒有教你的是：如何進行程式碼評審。你學習了演算法、資料結構，以及程式語言基礎，但沒有人坐下來說：“這是一些能讓你提出更好的反饋的辦法”。

程式碼評審是編寫良好軟體過程中的關鍵步驟。程式碼評審在於儘可能使得其具備高質量且 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、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。

相關文章