代碼檢查?可能是痛苦的。軟件工程師經常抱怨評審過程緩慢，延遲下游任務，并導致在打開請求(PR)和下一個任務之間來回導航時上下文切換。代碼審查也可能充滿了吹毛求疵和自行車欺騙，使其成為每個參與者的糟糕經歷。

為了解決這個問題，一些工程師甚至建議我們完全去掉拉請求和代碼審查。雖然這可能適用于初創企業的小型團隊，但我不認為這對每個人都是正確的解決方案，尤其是企業級別的公司。

相反，我們有很多方法可以使代碼審查過程對于代碼作者和代碼審查者來說都是一種更好的體驗。讓我們一起考慮其中的七個最佳實踐。

1.盡量少要求

每個工程師都害怕審查修改了1000多行代碼的請求。這些評審可能需要幾個小時才能完成，通常最終發生的情況是，評審人員開始瀏覽代碼，而不是仔細地評審代碼。

解決方案是保持您的拉請求很小。小型公關更容易、更快地進行評審，因為評審人員不需要花費那么多時間建立一個關于所有變更如何協同工作的心理模型。代碼更改也更少，這可能意味著更少的錯誤、更少的注釋以及作者和審閱者之間更少的來回。

保持你的公關規模小起初可能看起來很困難，但是如果你把你的工作分解成小任務并保持專注，這是可以做到的。在實現新特性或修復 bug 的同時，不要進行重大重構。在代碼中使用特性標志，這樣就可以將新特性的一小部分合并到主分支中，而不會在生產應用程序中顯示出來。

保持你的PRs小。你的審查員會感激你的。

2.使用拉請求模板

另一個麻煩是要求在沒有任何上下文的情況下檢查拉請求。當一個公關人員無緣無故地出現在你面前時，你經常會想: “這個公關是干什么的？這是在解決什么問題？是否有與此相關的任務？為什么要采取這種特殊的方法?”

Pull 請求模板是一個小型的、可配置的表單，您可以將其設置為每個新 pull 請求上的默認文本。PR 模板提示代碼作者為其 PR 提供相關細節。通常情況下，公關模板會要求簡要描述您所做的工作以及為什么要這樣做，任務票據的鏈接，以及驗證更改的測試計劃。

好的公關模板通常還包括一個簡短的清單，供代碼作者檢查，以確保他們沒有遺漏任何基本內容。此檢查表可能包括單元測試、文檔、國際化、跨瀏覽器支持和可訪問性等項目。

下面是一個例子拉請求模板，我喜歡使用的所有我的回購協議:

拉請求模板示例

3.實現響應時間 SLA

如果您發現拉請求未被審查的時間比您希望的要長，那么現在是一個好時機，作為一個團隊來設置對新的拉請求應該被審查的速度的預期。換句話說，一個公關在被提取之前最多可以存在多長時間: 一個小時？兩個小時？24小時？你對這個問題的回答很可能取決于你團隊的規模。對于來自團隊的內部拉動請求和來自其他團隊的外部拉動請求，您可能有不同的答案。

在選擇響應時間 SLA (服務水平協議)時，您需要找到正確的平衡。當你發布一個新的公關時，期望每個人都立即放下手頭的工作并審查你的代碼是不合理的，但是你也不希望公關連續幾個小時都沒有被審查。找到正確的平衡，讓你的隊友進入流動狀態。他們應該能夠處理自己的代碼，然后在一天中的自然停止點檢查 PR。

就個人而言，我喜歡對內部團隊公關有兩小時的響應時間，對外部團隊公關有24小時的響應時間。

不管你和你的隊友做出什么決定，擁有一個團隊協議可以讓你們彼此負責。如果每個人都同意一個特定的 SLA，并且時間已經過去了，你的公關之一，你知道這是可以開始竊聽人們關于它。

4.培訓初級和中級工程師

培訓機會無處不在。指導經驗不足的工程師不僅僅是教他們正在使用的技術和語言。它還包括教他們軟技能，比如如何進行有效的代碼審查。

在代碼檢查過程中，教會您的隊友您所尋找的東西。幫助他們明白什么是重要的，什么是不重要的。教他們如何在代碼評審注釋中有效地交流，比如在非阻塞建議前面加上“ nit”

有大量關于如何成為一個更有效的代碼審查員的資源。谷歌的代碼審查開發人員指南值得一讀。該指南對代碼作者和代碼審查者都有很好的建議。對于一個更厚顏無恥的資源，如何讓你的代碼審查員愛上你很容易是一些最好的(和有趣的)建議，為開發人員創建拉請求。

5.建立連續集成管道

當大多數注釋是“丟失分號”或“這里似乎沒有縮進”時，代碼檢查就變得乏味不要在代碼檢查期間花費時間在代碼格式化程序和代碼行程序可以為您處理的事情上。讓計算機自動處理瑣碎的事情，這樣你就可以專注于需要人力的重要事情。

對于 JavaScript 項目，為回購配置一個像 Prettier 這樣的格式化程序和一個像 ESLint 這樣的行程很簡單。然后，您可以使用諸如 Travis CI、 CircleCI、 GitHub Actions 或 GitLab CI/CD 之類的工具為回購建立持續集成。

CI 管道將為您運行這些格式化和連接任務以及單元測試。如果 CI 管道在請求的任何一個步驟中失敗，它將阻止合并該請求。

現在您已經自動完成了代碼審查的幾個重要部分，從而節省了您的時間。

6.使用拉請求審查應用程序

有時候，不僅需要檢查請求中的代碼，還需要手動查看應用程序中的更改，以驗證情況是否良好。對于具有復雜設置步驟的應用程序，下拉其他人的代碼并在您的計算機上本地運行它可能需要5分鐘到1小時。頭好痛！

每當創建一個新的 PR 時，拉請求審查應用程序都會自動將代碼部署到一個短暫的測試環境中。這使得評審員可以輕松地檢查 UI 更改，而不必下拉代碼并在他們的機器上本地運行。這不僅節省了時間，而且還促使評審人員在評審時更加全面，使其更加容易。

7.生成可視化代碼更改的圖表

在 GitHub 或 GitLab 中查看代碼時，文件通常以字母順序顯示。對于相對較小的公共關系，這可能不是一個問題。但是當一個公關涉及到幾十個文件時，有時候看到這些變化有邏輯地組合在一起是很有幫助的，這樣你就可以看到它們是如何在一個更大的圖片中組合在一起的。

CodeSee 查看地圖幫助您可視化哪些文件被更改，以及這些更改如何影響它們的上游或下游依賴關系。它們與 GitHub 集成，可以自動在您的 PR 上發布評論和圖表。您甚至可以創建代碼的交互式導覽，以幫助指導代碼審查人員。最棒的是，CodeSee Maps 對開源組織及其公共存儲庫是免費的。

CodeSee 映射?