[譯] 如何讓高效的程式碼評審成為一種文化

子非發表於2018-11-27

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

單元測試和程式碼評審

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

boyscout_rule

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

請遵循這個童子軍規，該規則建議評審人檢查單元測試是否支援在評審期間補充新程式碼和修復 bug，通過持續執行此操作，程式碼覆蓋率應該擴充套件或至少維持不變。舉個例子，如果程式碼覆蓋率下降，則評審人應向團隊解釋他/她遇到的困難以及不新增更多測試的原因。如果所有人都認可該解釋並且沒提出新問題，他/她可以繼續，否則，評審人應予以解決！

有效的程式碼評審小貼士

最高效的程式碼評審方式是結對程式設計，不過如果 GitHub 的 PR（Pull Request）適用於你的團隊，那麼 PR 同樣可行。為了搞定程式碼評審，我指的是完全搞定，我們首先應該嘗試提高程式碼評審流程的效率；我們的想法是把評審人當做稀缺的資源，因為我們的主要職責並不是程式碼評審，對不對？！

以下是有效並高效的程式碼評審的一些提示：

每次提交的改動儘量小

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 專案公示板

所有的靜態程式碼分析資料來自於 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）

參考

如果發現譯文存在錯誤或其他需要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。

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

相關文章