原文出處：https://dev.to/rchugunov/practical-tips-for-code-reviews-in-large-teams-25nb
改進程式碼審查流程對於旨在維持和提高效率和程式碼品質的開發團隊至關重要。越來越多的待處理拉取請求 (PR) 清單可能會令人不知所措，甚至令人士氣低落。透過完善審核流程，團隊可以確保 PR 的均衡分配，防止某些團隊成員被淹沒而其他成員閒置。爭取平等地花在公關上的時間有助於創造一個有凝聚力、和諧的團隊環境。此外，遵守旨在將審核時間控制在一個工作日的標準可保證快速反饋並促進動態、響應迅速的開發週期。最後，改進工作的本質是提高 PR 的質量，確保 PR 的規模最佳、準備充分且全面，從而簡化整個開發流程。
如何衡量程式碼審查的有效性
為了衡量程式碼審查流程的有效性，必須專注於團隊績效而不是個人貢獻。關鍵指標包括拉取請求 (PR) 接受審查的持續時間以及 PR 處於審查階段的時間相對於其總程式碼行數的時間。監控保持開放的 PR 數量以及每個 PR 中的程式碼量可以進一步深入了解審核流程的效率。
衡量團隊的效率而不是某些人的效率
測量 PR 處於審核狀態的時間。
測量 PR 處於審核狀態的時間除以程式碼行數。
處於開放狀態的 PR 數量。
PR 中的程式碼行
這可以透過引入收集 PR 資訊的工具來實現。如果你使用 Github，有一個 github 操作 issue-metrics 可以測量 PR 在一定時間內處於審核狀態的平均時間。但是您可以使用 Github API 建立自己的操作，該操作將收集對您的專案重要的資訊。
準備好你的 PR
始終首先向您的 PR 加入詳細描述。如果視覺表示有幫助，請考慮使用圖表。提出審核計劃也可以改變遊戲規則，引導審核者按照邏輯順序進行操作，確保任何更改都不會被忽視。
在您請求其他人深入研究您的程式碼之前，請先自己查看您的 PR 草案。透過這種自我審查，您可以發現並清除任何零散的評論或疏忽。
PR 中的評論應該澄清您的編碼決策，尤其是在可能出現混淆的情況下。例如，如果您在目前 PR 期間解決了一個不相關的錯誤，請提及它。這種先發制人的澄清可以讓審稿人省去很多麻煩。註釋充當更改的路線圖。透過引導審閱者查看特定文件或解釋某些修改背後的理由，您可以使他們的工作變得更簡單。額外的福利？您可能會在此註釋階段發現錯誤，甚至在審查開始之前修復它們。
如果您在 PR 中解決了多個問題，則可能需要將其分開。 PR 應該簡潔且重點突出。 經驗法則：如果更改涉及超過 5 個文件、花費了一天的時間來起草，或者需要大量的審查時間，則將其拆分。例如，一個 PR 可以為一項新功能佈置 API，而後續的 PR 可以展示實作。
如何查看別人的 PR
與任何其他任務一樣重視程式碼審查。在日曆中劃出專門用於複習的常規時間段。 快速回饋至關重要 - 開發人員等待的時間越長，上下文就會變得越模糊，從而使採納建議變得困難。
程式碼審查不僅僅是為了發現錯誤。它們提供了一個熟悉團隊不斷發展的功能和編碼原則的機會。抓住這個學習和成長的機會。
您在審核期間的評論應該清晰且具有建設性。模糊的言論可能會導致混亂。始終致力於提供回饋，指導開發人員實現預期的解決方案。
雖然像 GitHub 這樣的平台非常適合程式碼託管和初步審查，但它們可能不是最適合擴展討論的平台。考慮將長時間的對話轉移到像 Slack 這樣的平台上，以進行更有活力的交流。
對於大量拉取請求，將分支拉入本機開發環境可能會很有幫助。 IntelliJ Idea 等工具可以提供更身臨其境的差異視圖。請記住使用“git merge -no-commit -no-ff”等命令來查看更改，就像您所做的那樣。
如果您發現程式碼的某些部分難以掌握，請隨時向作者詢問清楚。最好停下來理解一下，而不是根據假設提供回饋。
審稿人分配演算法
有多種方法可以自動為 PR 指派審閱者。例如隨機或使用矩陣方法。 GitHub 提供了兩個策略 https://docs.github.com/en/organizations/organizing-members-into-teams/managing-code-review-settings-for-your-team#about-auto-assignment
另一種方法是製定自訂策略，其中每個團隊成員都有來自他的團隊的審核者列表，但也有來自其他團隊的兩名臨時審核者。
考慮團隊規模和功能交付速度，選擇最適合您團隊的方法。
程式碼審查的速度
雖然立即審查是理想的選擇，但並不總是可行。儘管如此，要遵守的黃金法則是24 小時時間範圍。目標是在一個工作天內回覆程式碼審查請求，即使這只是初步評估。這確保了程式碼不會停留在審查的邊緣，這可能會延遲後續的開發階段。
透過遵守此規則，如有必要，典型的變更清單 (CL) 可能會在一天內經歷多輪審核。如此快速的周轉不僅簡化了開發流程，而且還促進了審閱者和開發人員之間的動態討論，從而形成更加完善的程式碼庫。
如何處理審稿意見
不要只依賴 Github 評論，而是使用 Slack Github 連結 來促進 PR 上的溝通。它為即時互動提供了一個動態平台，使澄清疑慮、尋求解釋並就建議的變更達成共識變得更加容易。
如果您打算稍後解決特定評論或問題，請留下 TODO 標籤以及任務編號。這可以確保您對待處理的操作有清晰的路線圖，並且這些任務在未來的開發階段不會被忽略。
如果某個特定的程式碼部分引發了長時間的爭論，那麼記錄所做的決定就至關重要。 透過加入解釋選擇和理由的註釋，可以防止將來重複討論。它可以作為參考，確保未來的開發人員或審閱者了解特定程式碼片段背後的上下文和推理。
連結
Google指南：程式碼審查開發者指南
思科研究：https://static1.smartbear.co/support/media/resources/cc/book/code-review-cisco-case-study.pdf
Microsoft：來自 Microsoft 的 30 個經過驗證的程式碼審查最佳實踐 - McKayla 博士
更多關於 CR 的閱讀：https://blog.palantir.com/code-review-best-practices-19e02780015f
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
