[譯] 如何讓高效的代碼評審成爲一種文化

• 原文地址：Effective code review
• 原文做者：Bryan Liu
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：子非
• 校對者：7Ethan, smallfatS

如何提高代碼質量常常在某一段時間成爲開發團隊工做的重點，咱們積極地討論如何提高單元測試的效率，如何增長測試的代碼覆蓋率。然而好景不長，你們各忙各的，提高代碼質量的熱情也就慢慢降溫了。可是，但不超過一年，歷史又將重演，人們又將重提類似的觀點。個人名字叫 Bryan Liu，目前是在 LINE 從事自動化測試的一名質量工程師，我想分享在 LINE Taiwan 我是如何幫助改進單元測試和代碼評審進程的。

單元測試和代碼評審

正如在職培訓上 CTO 在向咱們解釋的同樣，同行代碼評審是 LINE 工程師文化的一部分。Facebook 指出開發過程當中最重要的三件事 —— 代碼評審、代碼評審和代碼評審。是的，解決單元測試和改進代碼質量的惟一方法是使單元測試成爲咱們工程師文化的一部分，而這就是代碼評審幫到咱們的地方。

針對代碼的童子軍規，來自 {codemotion}

請遵循這個童子軍規，該規則建議評審人檢查單元測試是否支持在評審期間補充新代碼和修復 bug，經過持續執行此操做，代碼覆蓋率應該擴展或至少維持不變。舉個例子，若是代碼覆蓋率降低，則評審人應向團隊解釋他/她遇到的困難以及不添加更多測試的緣由。若是全部人都承認該解釋而且沒提出新問題，他/她能夠繼續，不然，評審人應予以解決！

有效的代碼評審小貼士

最高效的代碼評審方式是結對編程，不過若是 GitHub 的 PR（Pull Request）適用於你的團隊，那麼 PR 一樣可行。爲了搞定代碼評審，我指的是徹底搞定，咱們首先應該嘗試提升代碼評審流程的效率；咱們的想法是把評審人當作稀缺的資源，由於咱們的主要職責並非代碼評審，對不對？！

如下是有效並高效的代碼評審的一些提示：

• 每次提交的改動儘可能小
• 常常評審並縮短評審時間
• 儘早發送 Pull Request 以供評審
• 提供足夠的背景信息使 Pull Request 旨意更明確
• Linting 和代碼風格檢查

每次提交的改動儘可能小

Cisco System 編程團隊的一項研究代表，對 200 到 400 LoC（代碼行）進行 60 到 90 分鐘的長時間評審能夠發現 70—90% 的缺陷。把每次 PR 的內容當作一個獨立單元處理（功能，bug 修復）或有意義的相關性強的想法。想了解爲何單次 Pull Request 提交大量代碼弊病繁多以及 Pull Request 的最佳量級，請看此處。

代碼評審，來自於 Twitter @iamdeveloper 與 缺陷密度 vs LoC，來自於 Cisco 研究案例。

常常評審並縮短評審時間

以合理的量級，較平穩的速度及利用有限的時間內進行代碼評審，能夠獲得最有效的評審結果。超過 400 LoC，發現缺陷的能力會下降。低於 300 LoC/hr 時檢驗效率是最好的。

缺陷密度與檢驗效率，來自於 Cisco 研究案例。

儘早發送 Pull Request 以供評審

爲了得到有價值的代碼評審，在細化實現前發起討論並儘可能避免提交很是大段的改動。將不一樣的想法分紅不一樣的 PR，而且根據須要分配給不一樣的評審人，將大問題分紅較小的問題並一次解決一個小問題。

若是在代碼評審的最後一分鐘發現架構/設計問題，該如何應用應急辦法，來自於 Twitter @isoiphone。

提供足夠的背景信息使 Pull Request 旨意更明確

評審人資源能作的十分有限，請明智地對待。

爲了幫助評審人快速進入問題背景，提供足夠的信息很是重要，例如改動的緣由和方案，以及潛藏的問題和須要關注的點。想要激發高效的討論，這些信息是必不可少的催化劑。做爲額外的好處，做者一般會在評審開始以前發現其餘錯誤。雖然不是每一個 PR 都值得寫出這樣的細節，可是你能夠簡單地註釋已經完成和測試的內容或者評審人應該更加關注哪一個部分！

GitHub Issue 和 Pull Request 模板可能會有所幫助。另外，附上截圖來描述您達成的效果是一個好主意！下面是幾個關於使用 PR 模板爲代碼評審和進一步 QA 驗證提供有意義背景的例子。

Github PR 模板示例

Linting 和編碼風格檢查

讓機器使用 SonarQube 和 ESLint 等工具進行靜態代碼分析和編碼風格檢查，爲業務邏輯和算法等重要環節節省注意力。這些代碼掃描工具、類型檢查工具和 linting 工具能夠報告錯誤，code smells 和漏洞，使用好的測試套件確定能夠提升代碼可靠度。

在 SonarQube 中發現問題，圖片來自於 SonarQube 站點

代碼評審中最重要的部分之一是獎勵開發人員的成長和努力，所以請提供儘量多的讚美。

最後，若是你沒法理解部分代碼，則沒法進行適當的評審。若是你的討論彷佛是反覆的，那就面對面地完成這部分討論，那樣會更有成效。

使之融入咱們的工程師文化

有人說「文化是即便沒人監督也會天然爲之的事」。在跳過代碼評審過程時，你是否仍會爲代碼編寫足夠的測試？不容易吧？但它仍然值得嘗試！若是您的項目採用了敏捷開發模式，請考慮如下因素，以使您的團隊文化能自我導向，不斷改進和學習：

• 自治：團隊成員以他們喜歡的方式承擔責任和工做（例如：Scrum，結對編程）
• 提高：持續執行良好的編碼實踐並經過代碼評審相互學習，最終能夠提升我的編碼技能
• 目標：代碼質量是咱們的最終目標，應該在早期發現錯誤而不是在生產中滅火

所以，爲了促進團隊文化建設，我開始嘗試如下兩個項目：

• 加強技能
• 評估進度

加強技能

是的，爲了深刻開展這項工做，開發人員還須要有全面的概念和完整的知識，才能在平常工做中達到團隊不斷增加的共識（實踐）。爲了幫助開發人員，咱們請來本地培訓機構開展有關單元測試，重構和 TDD（測試驅動開發）的培訓。

咱們在研討會上討論瞭如下主題（列出但不限於此）：

1. 單元測試
   • 設計測試用例用來展現目的，而不是測試代碼的實現
   • 須要識別並隔離依賴
   • 引入抽取和覆蓋以及依賴注入方法
   • 解釋 stub 和 mock 框架及斷言庫
   • 練習重構技巧，如抽取方法，內聯變量等等。
2. Kata（編程）着手於
   • 需求分析、優化方案並找出關鍵示例
   • 編碼設計和實現
3. TDD 和重構
   • Demo 重構，標識 code smells 及移除相關方法
   • 使用 TDD 方法進行實時編碼（例如：小步前進，紅綠燈）
   • 着手實踐

研討會期間的照片

評估進度

若是你不瞭解進度，你就無從評估進度，更沒法提高進度！

咱們運用公示屏展現分析結果並經過消息通知持續推送最新進度，強大的視覺效果增長了你們的參與度，爲了同一個目標咱們共同努力。位於門口的大型公示屏會循環展現以下信息。

• SonarQube 項目公示板（dashboard）
• 基於團隊的代碼覆蓋率
• PR 的大小與解決時間
• PR 評論通知

SonarQube 項目公示板

全部的靜態代碼分析數據來自於 SonarQube，直接連接到生產服務的代碼倉庫應該在這裏發佈報告。

基於團隊的代碼覆蓋率

基於團隊的代碼覆蓋率圖表顯示了團隊中每一個倉庫的覆蓋趨勢，所以無需導航到每一個 SonarQube 項目頁面。經過將這種類型的圖表並排放置，能夠很容易地比較不一樣團隊的表現。

PR 的大小與解決時間

DevOps 的核心思想是如何將軟件變動頻繁地發佈到生產中，同時保證質量。使每一個部署單元變小是這裏的訣竅。大型 PR 不只沒法進行良好的代碼評審，並且還會增長在代碼質量和發佈週期成本，所以對於 DevOps 將任務/變動作小是行之有效的技能。咱們嘗試使用如下「分辨率時間與 PR 大小」圖表來推動這一理念：

• 氣泡大小：更改設置大小（代碼行）
• 解決時間：PR 建立時間到 PR 合併時間
• #n：PR 號

這些圖表持續提醒每一個人採用良好實踐和追求目標的進度。這些只是咱們在這裏作的一些例子。想一想你本身能夠直觀地向別人展現你的意圖。順便說一下，這些對於月度會議期間總結進展也頗有用。

PR 評論通知

提交給 PR 的每次提交都會觸發一個 webhook 來發布 github 評論，以下所示。這是爲了提醒 PR 建立者添加測試並修復在此 PR 內部發現的新漏洞，這比在兩週後把更改發佈到生產中更爲有效。爲了提升質量指標，評審人還應該幫助找出被評審人遇到問題的緣由。

• 最新 n 次提交的平均值: 展現每種指標的趨勢
• xxx 次問題：發現的 bug，漏洞和 code smells 的數量
• 代碼覆蓋率：執行單元測試的 LoC 百分比

總結與將來計劃

爲了給代碼評審討論提供很好的環境，知曉如何編寫整潔的代碼以及如何識別 code smell 並刪除相當重要，只有團隊真正下功夫解決這些常見問題，文化才能隨之培養。

另外一方面，沒用的指標不須要跟蹤；顯示數據隨時間變化的趨勢很重要，它提供給咱們作出相應措施的背景。看看上圖中顯示的趨勢線隨着進展而變化。此外，咱們還考慮添加更多公示板展現如下內容：

• 質量：開啓/關閉的 bug 數，同時展現嚴重性和缺陷密度
• 速度：部署頻率，生產前導時間，修改失敗率和平均恢復時間（MTTR）

參考

• [Gerrit] 代碼評審 — 貢獻
• [Phabricator] 編寫可評審的代碼
• [Phabricator] 差別用戶指南：測試計劃
• [MSFT] 代碼評審和軟件質量，實踐研究成果
• [Cisco] 代碼評審的最佳實踐
• [Book] 加速：依靠軟件和 DevOps 的科學
• [驅動力] 關於激勵他人的驚人事實

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

---

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