Code Review Guidelines · Gitlab 中文文檔

# Code Review Guidelines > 原文：[https://docs.gitlab.com/ee/development/code_review.html](https://docs.gitlab.com/ee/development/code_review.html) * [Getting your merge request reviewed, approved, and merged](#getting-your-merge-request-reviewed-approved-and-merged) * [Domain experts](#domain-experts) * [Reviewer roulette](#reviewer-roulette) * [Approval guidelines](#approval-guidelines) * [Security requirements](#security-requirements) * [The responsibility of the merge request author](#the-responsibility-of-the-merge-request-author) * [The responsibility of the reviewer](#the-responsibility-of-the-reviewer) * [The responsibility of the maintainer](#the-responsibility-of-the-maintainer) * [Best practices](#best-practices) * [Everyone](#everyone) * [Having your merge request reviewed](#having-your-merge-request-reviewed) * [Assigning a merge request for a review](#assigning-a-merge-request-for-a-review) * [List of merge requests ready for review](#list-of-merge-requests-ready-for-review) * [Reviewing a merge request](#reviewing-a-merge-request) * [Merging a merge request](#merging-a-merge-request) * [The right balance](#the-right-balance) * [GitLab-specific concerns](#gitlab-specific-concerns) * [Review turnaround time](#review-turnaround-time) * [Review-response SLO](#review-response-slo) * [Customer critical merge requests](#customer-critical-merge-requests) * [Examples](#examples) * [Credits](#credits) # Code Review Guidelines[](#code-review-guidelines "Permalink") 本指南包含有關執行代碼審查和代碼審查的建議和最佳實踐. 無論是由 GitLab 團隊成員還是志愿者貢獻者編寫的所有對 GitLab CE 和 EE 的合并請求，都必須經過代碼審查流程，以確保代碼有效，可理解，可維護和安全. ## Getting your merge request reviewed, approved, and merged[](#getting-your-merge-request-reviewed-approved-and-merged "Permalink") 強烈建議您讓您的代碼通過**審核** [評審](https://about.gitlab.com/handbook/engineering/workflow/code-review/#reviewer) ，一旦有任何代碼評審，獲得所選擇的解決方案和實施，和一個額外的一雙眼睛尋找錯誤，邏輯問題，或裸露邊緣的第二意見案件. 默認方法是從您的小組或團隊中選擇一名審閱者進行第一次審閱. 這只是一個建議，審閱者可能來自其他團隊. 但是，建議選擇一個[領域專家](#domain-experts) . 您可以在下面有關作者責任的部分中詳細了解讓審稿人參與的重要性. 如果您需要一些指導（例如，這是您的第一個合并請求），請隨時咨詢一位[合并請求教練](https://about.gitlab.com/company/team/) . 如果您需要有關安全掃描或注釋的幫助，請隨時在評論中包括安全團隊（ `@gitlab-com/gl-security` ）. 根據您的合并請求涉及的領域，它必須由一個或多個[維護者](https://about.gitlab.com/handbook/engineering/workflow/code-review/#maintainer) **批準** ：對于批準，我們使用合并請求小部件中的批準功能. 審閱者可以通過[額外](../user/project/merge_requests/merge_request_approvals.html#adding-or-removing-an-approval)批準來添加其批準. 讓您的合并請求也**合并**需要一個維護者. 如果需要多個批準，則最后一個對其進行審核的維護者也會將其合并. ### Domain experts[](#domain-experts "Permalink") 領域專家是在特定技術，產品功能或代碼庫領域具有豐富經驗的團隊成員. 鼓勵團隊成員自認是領域專家，并將其添加到他們的[團隊資料中](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/team.yml) 當自我確定為領域專家時，建議分配更改`team.yml`的 MR，以由已經建立的領域專家或相應的工程經理進行合并. 對于自動被視為領域專家，我們做出以下假設： * 在特定階段/小組中工作的團隊成員（例如，創建：源代碼）被視為他們所從事的應用程序領域的領域專家 * 從事特定功能（例如搜索）的團隊成員被視為該功能的領域專家我們默認為具有領域專業知識的團隊成員分配評論. 如果沒有合適的[領域專家](#domain-experts) ，您可以選擇任何團隊成員來審核 MR，也可以按照" [審核者"輪盤賭的](#reviewer-roulette)建議進行操作. 可以在[工程項目](https://about.gitlab.com/handbook/engineering/projects/)頁面或[GitLab 團隊頁面](https://about.gitlab.com/company/team/)上查看團隊成員的領域專業知識. ### Reviewer roulette[](#reviewer-roulette "Permalink") [Danger 機器人會](dangerbot.html)為您的合并請求似乎接觸的每個代碼庫區域隨機選擇一個審閱者和一個維護者. 它僅提出**建議** ，如果您認為其他人更適合，則應予以覆蓋！它從[工程項目](https://about.gitlab.com/handbook/engineering/projects/)頁面的列表中選擇審閱者和維護者，具有以下行為： 1. 它不會選擇[GitLab 狀態](../user/profile/index.html#current-status)包含字符串'OOO'或表情符號為`:palm_tree:`或`:beach:` . 2. [培訓生的維護者](https://about.gitlab.com/handbook/engineering/workflow/code-review/#trainee-maintainer)被[選拔的](https://about.gitlab.com/handbook/engineering/workflow/code-review/#trainee-maintainer)可能性是其他審閱者的三倍. 3. 它始終為相同的分支名稱選擇相同的審閱者和維護者（除非他們的 OOO 狀態更改，如第 1 點所示）. 它消除導致`ce-`和`ee-`和尾`-ce`和`-ee` ，以便它可以為反向移植分支穩定. ### Approval guidelines[](#approval-guidelines "Permalink") 如下面有關維護者職責的部分所述，建議您讓合并請求由具有[域專業知識的](#domain-experts)維護者批準并合并. 1. 如果您的合并請求包含后端更改（ *1* ），則必須**由[后端維護者](https://about.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_backend)批準** . 2. 如果您的合并請求包括數據庫遷移或對昂貴查詢的更改（ *2* ），則必須得到**[數據庫維護者的](https://about.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_database)批準** . 閱讀[數據庫復查指南](database_review.html)以獲取更多詳細信息. 3. 如果您的合并請求包含前端更改（ *1* ），則必須得到**[前端維護者的](https://about.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_frontend)批準** . 4. 如果您的合并請求包括用戶體驗更改（ *1* ），則必須得到用戶**[體驗團隊成員的](https://about.gitlab.com/company/team/)批準** . 5. 如果您的合并請求包括添加新的 JavaScript 庫（ *1* ），則必須得到**[前端領導的](https://about.gitlab.com/company/team/)批準** . 6. 如果您的合并請求包括添加新的 UI / UX 范例（ *1* ），則必須**由[UX 主管](https://about.gitlab.com/company/team/)批準** . 7. 如果您的合并請求包含新的依賴項或文件系統更改，則必須得到**[分發團隊成員的](https://about.gitlab.com/company/team/)批準** . 有關更多詳細信息，請參見如何與[發行團隊](https://about.gitlab.com/handbook/engineering/development/enablement/distribution/#how-to-work-with-distribution)合作. 8. 如果您的合并請求中包含文檔更改，則必須根據相應的[產品類別](https://about.gitlab.com/handbook/product/product-categories/) **由[技術撰稿人](https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers)批準** . 9. 如果您的合并請求包含端到端**和**非端到端更改（ *3* ），則必須**經過[測試中](https://about.gitlab.com/handbook/engineering/quality/#individual-contributors)的[軟件工程師的](https://about.gitlab.com/handbook/engineering/quality/#individual-contributors)批準** . 10. 如果您的合并請求僅包含端到端更改（ *3* ）， **或者**如果 MR 作者是[測試中](https://about.gitlab.com/handbook/engineering/quality/#individual-contributors)的[軟件工程師](https://about.gitlab.com/handbook/engineering/quality/#individual-contributors) ，則必須得到**[質量維護人員的](https://about.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_qa)批準** * （ *1* ）：請注意，除 JavaScript 規范以外的其他規范均被視為后端代碼. * （ *2* ）：如果您的合并請求可能引入昂貴的查詢，我們鼓勵您從數據庫維護者那里尋求指導. 用 SQL 查詢在相關代碼行中注釋是最有效的，這樣他們就可以給出建議. * （ *3* ）：端到端更改包括`qa`目錄中的所有文件. #### Security requirements[](#security-requirements "Permalink") View the updated documentation regarding [internal application security reviews](https://about.gitlab.com/handbook/engineering/security/#internal-application-security-reviews) for **when** and **how** to request a security review. ### The responsibility of the merge request author[](#the-responsibility-of-the-merge-request-author "Permalink") 找到最佳解決方案并實施該解決方案的責任在于合并請求作者. 在將合并請求分配給維護者進行批準和合并之前，他們應該確信： * 它實際上解決了本應解決的問題. * 它以最合適的方式這樣做. * 滿足所有要求. * 沒有剩余的錯誤，邏輯問題，未發現的極端情況或已知的漏洞. 做到這一點并避免與審閱者不必要的來回交流的最佳方法是，按照[代碼審閱](#reviewing-a-merge-request)指南對自己的合并請求進行自審. 為了使他們的解決方案達到所需的置信度，作者應酌情讓其他人參與調查和實施過程. 鼓勵他們與[領域專家聯系](#domain-experts) ，討論不同的解決方案或對實現進行審查，與產品經理和 UX 設計師聯系，以消除混亂或驗證最終結果是否與他們的想法相符，并與數據庫專家聯系，以獲取有關數據模型或特定查詢，或者讓任何其他開發人員深入了解該解決方案. 如果作者不確定合并請求是否需要[領域專家的](#domain-experts)意見，這通常是一個很好的信號，因為如果沒有合并請求，將無法達到他們對解決方案所要求的置信度. 在審閱之前，請作者針對合并請求差異提交評論，以提醒審閱者重要的事項以及需要進一步解釋或關注的事項. 可能需要發表評論的內容示例包括： * 增加了起毛規則（Rubocop，JS 等）. * 增加了一個庫（Ruby gem，JS lib 等）. * 如果不明顯，則指向父類或方法的鏈接. * 進行任何基準測試以補充變更. * 潛在的不安全代碼. Avoid: * 除非審閱者要求您將注釋（上面引用的或 TODO 項）直接添加到源代碼中. 如果由于可執行的任務而添加了注釋，則必須包含指向問題的鏈接. * 將測試失敗的合并請求分配給維護人員. 如果測試失敗，則必須分配，請確保在評論中留下說明. * 通過電子郵件或 Slack 過多提及維護者（如果可以通過 Slack 與維護者聯系）. 如果您不能分配合并請求，則`@`可以在注釋中提及維護者，在所有其他情況下，分配合并請求就足夠了. This [saves reviewers time and helps authors catch mistakes earlier](https://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/index.html#__RefHeading__97_174136755). ### The responsibility of the reviewer[](#the-responsibility-of-the-reviewer "Permalink") 徹底[檢查合并請求](#reviewing-a-merge-request) . 當您確信它滿足所有要求時，您應該： * Click the Approve button. * 告知作者他們的合并請求已經過審核和批準. * 將合并請求分配給維護者. 默認情況下，將其分配給具有[領域專業知識](#domain-experts)的維護者，但是，如果不可用，或者您認為合并請求不需要[領域專家](#domain-experts)的審查，請隨時遵循" [審閱者"輪盤賭的](#reviewer-roulette)建議. ### The responsibility of the maintainer[](#the-responsibility-of-the-maintainer "Permalink") 維護人員負責跨領域和產品領域的 GitLab 代碼庫的總體運行狀況，質量和一致性. 因此，他們的審查將主要集中在總體架構，代碼組織，關注點分離，測試，DRYness，一致性和可讀性等方面. 由于維護人員的工作僅取決于他們對整個 GitLab 代碼庫的了解，而不取決于任何特定領域的知識，因此他們可以查看，批準和合并來自任何團隊和任何產品領域的合并請求. 維護人員將盡最大努力在合并之前檢查所選解決方案的詳細信息，但是由于他們不一定是[領域專家](#domain-experts) ，因此他們可能沒有太多時間來浪費很多時間. 在這種情況下，他們將服從作者和早期審稿人的判斷，而將精力放在他們的主要職責上. 如果維護者認為 MR 足夠重要，足以保證需要由[域專家](#domain-experts)進行審查，并且目前尚不清楚域專家是否參與了審查，則他們可以在合并 MR 之前要求[域專家進行](#domain-experts)審查. 如果恰好也是維護者的開發人員作為審閱者參與了合并請求，則建議不要同時選擇他們作為維護者來最終批準并合并它. 維護人員應在合并之前檢查合并請求是否已被所需批準者批準. 維護人員必須在合并之前檢查合并請求[安全性小部件中](../user/application_security/index.html)的列表，以檢查合并請求是否引入了新的漏洞. 如有疑問，可以請[安全工程師](https://about.gitlab.com/company/team/)參與. 檢測到的漏洞列表必須為空或包含以下內容： * 在出現誤報的情況下消除漏洞 * 漏洞轉化為問題維護人員**切勿**在沒有適當驗證的情況下消除漏洞以"清空"列表. 請注意，某些合并請求可能會針對穩定分支. 這些是罕見的事件. 維護者無法合并這些類型的合并請求. 相反，這些應該發送到[版本管理器](https://about.gitlab.com/community/release-managers/) . ## Best practices[](#best-practices "Permalink") ### Everyone[](#everyone "Permalink") * 善待. * 接受許多編程決策是意見. 討論您喜歡的折衷方案，并迅速解決. * 問問題; 不要提出要求. （"您如何命名這個`:user_id` ？"） * 要求澄清. （"我聽不懂.您能澄清一下嗎？"） * 避免有選擇地擁有代碼. （"我的"，"不是我的"，"您的"） * 避免使用可能被視為涉及個人特質的術語. （"啞巴"，"愚蠢"）. 假設每個人都是有吸引力，聰明和善良的. * 要明確. 請記住，人們并不總是在線了解您的意圖. * 要謙虛. （"我不確定-讓我們看一下."） * 不要夸張. （"始終"，"從不"，"無限"，"無"） * 使用諷刺時要小心. 我們所做的一切都是公開的；對于您和長期的同事而言，似乎很老套的話可能會很卑鄙，不歡迎新加入該項目的人. * 如果"我聽不懂"或"替代解決方案："注釋過多，請考慮一對一聊天或視頻通話. 發表后續評論，總結一對一的討論. * 如果您向特定人員提出問題，請務必先提及他們，然后再開始評論；如果將通知級別設置為"提及"，這將確保他們看到該消息，并且其他人將理解他們不必響應. ### Having your merge request reviewed[](#having-your-merge-request-reviewed "Permalink") 請記住，代碼審閱是一個可能需要多次迭代的過程，審閱者可能會在以后發現他們第一次看不到的東西. * 您的代碼的第一位審閱者是*you* . 在對閃亮的新分支進行第一次推送之前，請通讀整個差異. 是否有意義？您是否包含與變更的總體目的無關的內容？您是否忘記刪除任何調試代碼？ * 感謝審閱者的建議. （"好電話.我會進行更改."） * 不要親自去做. 審閱的是代碼，而不是您的. * 說明代碼為何存在. （"由于這些原因就這樣.如果重命名這個類/文件/方法/變量，是否更清楚？"） * 將不相關的更改和重構提取到將來的合并請求/問題中. * 試圖了解審稿人的觀點. * 嘗試回應每個評論. * 合并請求作者僅解析他們已完全解決的線程. 如果有公開的答復，公開的話題，建議，問題或其他任何內容，則該話題應留待審閱者解決. * 不應假定所有反饋都要求在合并之前將其建議的更改合并到 MR 中. 這是 MR 作者和審閱者對是否需要這樣做的判斷，或者是在合并有問題的 MR 之后是否應創建后續問題以解決將來的反饋. * 基于較早回饋的推送提交作為對分支的獨立提交. 在分支準備好合并之前，請勿壓扁. 審閱者應該能夠根據他們先前的反饋來閱讀各個更新. * 準備好進行另一輪審核后，將合并請求分配回審核者. 如果您無法分配合并請求，請`@`提及審閱者. ### Assigning a merge request for a review[](#assigning-a-merge-request-for-a-review "Permalink") 準備好要審核合并請求時，默認應將其分配給小組或團隊中的審閱者以進行第一次審閱，但是，您也可以將其分配給任何審閱者. 審閱者列表可以在" [工程項目"](https://about.gitlab.com/handbook/engineering/projects/)頁面上找到. You can also use `workflow::ready for review` label. That means that your merge request is ready to be reviewed and any reviewer can pick it. It is recommended to use that label only if there isn’t time pressure and make sure the merge request is assigned to a reviewer. 在審核合并請求并將其傳遞給維護者后，您應該默認選擇具有[領域專業知識](#domain-experts)的維護者，否則應遵循 Reviewer Roulette 的建議或使用`ready for merge`的標簽. 合并請求的作者有責任審查合并請求. 如果`ready for review`狀態太長時間，建議將其分配給特定的審閱者. #### List of merge requests ready for review[](#list-of-merge-requests-ready-for-review "Permalink") 有能力的開發人員可以定期檢查[合并請求](https://gitlab.com/groups/gitlab-org/-/merge_requests?state=opened&label_name[]=workflow::ready for review)列表[以進行審核，](https://gitlab.com/groups/gitlab-org/-/merge_requests?state=opened&label_name[]=workflow::ready for review)并分配他們要審核的任何合并請求. ### Reviewing a merge request[](#reviewing-a-merge-request "Permalink") 了解為什么需要進行更改（修復錯誤，改善用戶體驗，重構現有代碼）. 然后： * 嘗試在您的評論中做到周密，以減少迭代次數. * 交流您對哪些想法有強烈的想法，而哪些想法則沒有. * 確定在解決問題的同時簡化代碼的方法. * 提供替代的實現，但是假設作者已經考慮了它們. （"您在這里對使用自定義驗證器有何看法？"） * 試圖了解作者的觀點. * 如果您不懂一段代碼，請*這樣說* . 很有可能其他人也會對此感到困惑. * 確保作者清楚他們需要什么來解決/解決該建議. * 考慮使用[常規注釋格式](https://conventionalcomments.org#format)來傳達您的意圖. * 對于非強制性建議，請使用（非阻塞）修飾，以便作者知道可以選擇在合并請求中解決該問題，或者在以后進行后續操作. * 經過幾行注釋后，發布摘要注釋（例如"對我很好"或"僅幾件要解決的問題"）會很有幫助. * 如果審閱后需要更改，則將合并請求分配給作者. ### Merging a merge request[](#merging-a-merge-request "Permalink") 在決定合并之前： * 設置里程碑. * 考慮來自危險漫游器，代碼質量和其他報告的警告和錯誤. 除非有充分的理由證明違規，否則應在合并前解決這些問題. 如果 MR 與任何失敗的作業合并，則必須發布評論. * 如果 MR 既包含與質量相關的變更，又包含與非質量無關的變更，則應由相關維護人員合并 MR，以便在測試中軟件工程師批準與質量相關的變更后，將其面向用戶的變更（后端，前端或數據庫）. 如果合并請求從根本上準備就緒，但僅需要簡單的修正（例如拼寫錯誤），則可以考慮通過直接進行更改而不向作者證明是[對行動](https://about.gitlab.com/handbook/values/#bias-for-action)的[偏見](https://about.gitlab.com/handbook/values/#bias-for-action) . 您可以通過使用" [建議更改"](../user/discussions/index.html#suggest-changes)功能將自己的建議應用于合并請求來實現. 注意： * 如果更改不直接，請優先將合并請求分配回作者. * **在應用建議之前** ，請編輯合并請求以確保啟用了[壓縮和合并](../user/project/merge_requests/squash_and_merge.html#squash-and-merge) ，否則，管道的"危險"作業將失敗. * 如果合并請求未啟用壓縮和合并，并且具有多個提交，則請參閱以下有關重寫提交歷史記錄的注釋. 準備合并時： * 當合并請求包含大量提交時，請考慮使用[Squash 和合并](../user/project/merge_requests/squash_and_merge.html#squash-and-merge)功能. 合并代碼時，維護者僅應在作者已設置此選項或合并請求中明確包含要壓縮的混亂提交歷史記錄時使用 squash 功能. * **使用合并請求的"管道"選項卡中的" `Run Pipeline`按鈕啟動新的合并請求管道，并啟用"管道成功時合并"（MWPS）.** 注意： * 如果**最新[的合并結果管道](../ci/merge_request_pipelines/pipelines_for_merged_results/#pipelines-for-merged-results-premium)**不到 2 小時前完成，則由于合并請求足夠接近`master` ，您可能無需啟動新管道就可以合并. * 如果**合并請求來自 fork** ，則我們不能將[管道用于合并結果](../ci/merge_request_pipelines/pipelines_for_merged_results/index.html#prerequisites) ，因此，它們更容易破壞`master` . 檢查源分支在`master` . 如果超過 100 次提交，請在合并之前要求作者重新設置基礎. * 如果[master 已損壞](https://about.gitlab.com/handbook/engineering/workflow/#broken-master) ，除了上述兩個規則外，請檢查`master`是否也發生任何故障，并在單擊紅色的" Merge"（合并）按鈕之前發布指向?" master：broken"問題的鏈接. * 當將 MR 設置為"管道成功合并時"時，您應該接管后續修訂，以應對之后發現的所有問題. **注意：**感謝"合并結果管道"，由于合并結果管道已經合并了`master`的最新更改，因此作者不必再頻繁地重新建立分支基礎（僅當發生沖突時）. 由于維護人員不必要求最終的重新定基，因此可以加快審核/合并周期：相反，他們只需要啟動 MR 管道并設置 MWPS. 通過在創建管道時針對最新`master`測試合并結果，此步驟使我們非常接近實際的合并訓練功能. ### The right balance[](#the-right-balance "Permalink") 在代碼審查期間，最困難的事情之一是在審查者可以干擾作者創建的代碼的深度上找到適當的平衡. * 學習如何找到合適的平衡點需要花費時間. 這就是為什么我們花了一些時間審核合并請求后使審核員成為維護者的原因. * 查找錯誤很重要，但是考慮良好的設計也很重要. 建立抽象和良好的設計可以隱藏復雜性并使將來的更改變得容易. * 強制和改進[代碼樣式](contributing/style_guides.html)應主要通過[自動化](https://about.gitlab.com/handbook/values/#cleanup-over-sign-off)而不是評論注釋來完成. * 要求作者更改設計有時意味著完全重寫貢獻的代碼. 通常，在進行此操作之前先詢問其他維護者或審閱者是一個好主意，但是當您認為重要時，要有勇氣去做. * 為了[Iteration](https://about.gitlab.com/handbook/values/#iteration)的利益，如果您的審查建議是非阻塞性更改或個人喜好（不是書面或約定的要求），請考慮批準合并請求，然后再將其傳遞回作者. 如果他們同意，這將使他們能夠實施您的建議，或者使他們立即將其傳遞給維護者以供審核. 這可以幫助減少我們的整體合并時間. * 做正確的事和立即做事有區別. 理想情況下，我們應該做前者，但在現實世界中，我們也需要后者. 一個很好的例子是安全修復程序，應盡快發布. 應該避免要求作者在合并請求中進行重大重構，這是一個緊急解決方案. * 今天做好事通常比明天做好事更好. 今天運送垃圾通常比明天做好事更糟. 當您找不到合適的平衡時，請向其他人詢問他們的意見. ### GitLab-specific concerns[](#gitlab-specific-concerns "Permalink") GitLab 在很多地方都使用過. 許多用戶使用我們的[Omnibus 軟件包](https://about.gitlab.com/install/) ，但有些用戶使用[Docker 映像](https://docs.gitlab.com/omnibus/docker/) ，有些是[從源代碼安裝的](../install/installation.html) ，還有其他可用的安裝方法. GitLab.com 本身是一個大型企業版實例. 這有一些含義： 1. 應該對**查詢更改**進行測試，以確保在 GitLab.com 規模上不會導致性能下降： 1. 在本地生成大量數據會有所幫助. 2. 從 GitLab.com 詢問查詢計劃是驗證這些計劃的最可靠方法. 2. **數據庫遷移**必須是： 1. 可逆的. 2. 性能達到 GitLab.com 的規模-如果不確定，請維護人員在登臺環境中測試遷移. 3. 正確分類： * 常規遷移在新代碼在實例上運行之前運行. * 將實例配置為執行新[部署](post_deployment_migrations.html) *后* ，便會進行部署*后* [遷移](post_deployment_migrations.html) . * [后臺遷移](background_migrations.html)在 Sidekiq 中運行，并且僅應在 GitLab.com 規模上花費大量時間進行遷移. 3. **Sidekiq 工人** [cannot change in a backwards-incompatible way](sidekiq_style_guide.html#sidekiq-compatibility-across-updates): 1. 在部署發生之前，不會耗盡 Sidekiq 隊列，因此隊列中會有來自上一版 GitLab 的工作線程. 2. 如果需要更改方法簽名，請嘗試在兩個版本中進行更改，并在第一個版本中同時接受新舊參數. 3. 同樣，如果您需要刪除一個工作程序，請停止在一個版本中計劃它，然后在下一個版本中將其刪除. 這將允許現有作業執行. 4. Don’t forget, not every instance will upgrade to every intermediate version (some people may go from X.1.0 to X.10.0, or even try bigger upgrades!), so try to be liberal in accepting the old format if it is cheap to do so. 4. **緩存的值**可能會在各個發行版中持續存在. 如果要更改緩存值返回的類型（例如，從字符串或 nil 到數組），請同時更改緩存鍵. 5. **設置**應作為[最后的手段](https://about.gitlab.com/handbook/product/#convention-over-configuration)添加. 如果要在`gitlab.yml`添加新設置： 1. 嘗試避免這種情況，而是添加到`ApplicationSetting` . 2. 確保它也已[添加到 Omnibus 中](https://docs.gitlab.com/omnibus/settings/gitlab.yml.html) . 6. **文件系統訪問**可能很慢，因此，在有替代解決方案可用時，請嘗試避免[共享文件](shared_files.html) . ### Review turnaround time[](#review-turnaround-time "Permalink") 由于[取消阻止其他人始終是頭等大事](https://about.gitlab.com/handbook/values/#global-optimization) ，因此，即使這可能會對他們的其他任務和優先事項產生不利影響，審閱者也應及時查看分配的合并請求. 這樣做使合并請求中涉及的每個人都可以在上下文處于內存中新鮮時更快地進行迭代，并顯著改善了貢獻者的體驗. #### Review-response SLO[](#review-response-slo "Permalink") 為了確保快速反饋到準備就緒的代碼，我們維護了一個`Review-response`服務級別目標（SLO）. SLO 定義為： > * 審核響應 SLO =（提供第一次審核響應的時間）-（將 MR 分配給審核者的時間）<2 個工作日如果您認為您無法在" `Review-response` SLO 期限內審閱合并請求，請讓作者盡快知道，并嘗試幫助他們找到其他能夠審閱的審閱者或維護者，因此他們可以暢通無阻，并迅速開始工作. 如果您認為自己有能力并且在完成一些評論之前無法接受其他評論，請通過設置`:red_circle:`表情符號并在狀態文本中提及您有能力，通過 GitLab 狀態傳達此信息. 這將指導撰稿人選擇其他審稿人，從而幫助我們滿足 SLO. 當然，如果您不在辦公室并且已通過 GitLab.com 狀態[傳達了](https://about.gitlab.com/handbook/paid-time-off/#communicating-your-time-off)此信息，則作者應意識到這一點，并自己找一位不同的審稿人. 當合并請求作者的阻止時間超過`Review-response` SLO 時，他們可以自由地通過 Slack 提醒審閱者或分配其他審閱者. ### Customer critical merge requests[](#customer-critical-merge-requests "Permalink") 合并請求可能會因為被視為客戶關鍵優先級而受益，因為這樣做會使企業受益匪淺. 客戶關鍵合并請求的屬性： * [發展高級總監](https://about.gitlab.com/job-families/engineering/engineering-management/#senior-director-engineering) （ [](https://gitlab.com/clefelhocz1)[@ clefelhocz1](https://gitlab.com/clefelhocz1) ）是用于確定合并請求是否對客戶至關重要的 DRI. * DRI 將`customer-critical-merge-request`標簽分配給合并請求. * 要求與客戶關鍵合并請求相關的審閱者和維護者一經做出此決定，便立即參與. * 需要優先處理涉及客戶關鍵合并請求的人員的工作，以便他們有足夠的時間專注于此. * 在處理客戶關鍵的合并請求時，必須遵守 GitLab 的[價值觀](https://about.gitlab.com/handbook/values/)和流程，首先要特別注意家人和朋友，其次要注意，完成的定義，迭代以及準備就緒時發布. * 需要客戶關鍵的合并請求，以免降低安全性，引入數據丟失風險，降低可用性或破壞每個流程的現有功能，從而[優先考慮技術決策](https://about.gitlab.com/handbook/engineering/#prioritizing-technical-decisions.md) . * 對于客戶的關鍵請求，如果他們認為這將減少花費的合并時間（即使這*可能*會降低[效率](https://about.gitlab.com/company/culture/all-remote/asynchronous/#evaluating-efficiency.md) ），則*建議*相關人員*考慮*除了異步（合并請求注釋）之外，還同步進行協調（Zoom，Slack）. * 合并客戶關鍵合并請求后，必須完成回顧，以減少將來的客戶關鍵合并請求的頻率. ## Examples[](#examples "Permalink") 如何進行代碼審查可能會使新的參與者感到驚訝. 以下是一些代碼審查示例，它們可以幫助您確定期望的方向. **["修改`DiffNote`以便將其重新用于設計"](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/13703) ：**它包含了從換行符轉折點到設計版本的推理，如果沒有某個文件的先前版本，我們應該如何比較它們的所有內容（父級 vs.空白`sha`空白樹））. **["支持多行建議"](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/25211)** ：MR 本身由 FE 和 BE 之間的協作組成，并記錄了作者對審閱者的評論. 有一些缺點，一些有關信息的問題，最后還有一個安全漏洞. **["每個項目允許有多個存儲庫"](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/10251)** ：ZJ 提到了這可能會影響的其他項目（工作馬），并建議進行一些改進以保持一致性. James 的評論幫助我們提高了整體代碼質量（使用委派`&.`這些類型的事情），并使代碼更加健壯. **["支持多個受讓人進行合并請求"](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/10161)** ：MR 接觸代碼庫多個部分的一個很好的示例. 尼克指出了一些有趣的例子，詹姆斯·洛佩茲（James Lopez）也加入了對進出口功能的關注. ### Credits[](#credits "Permalink") 很大程度上基于[thinkbot 代碼的審查指南](https://github.com/thoughtbot/guides/tree/master/code-review) . * * * [Return to Development documentation](README.html)