代碼審查標準

代碼審查的主要目的是確保google代碼庫的整體代碼運行狀況隨著時間的推移而不斷改善。為此目的，設計了所有代碼審查的工具和過程。

為了實現這一點，必須權衡一系列折衷。

首先，開發人員必須能夠在其任務上取得進展。如果您從未向代碼庫提交過改進，那么代碼庫將永遠不會得到改進。另外，如果審閱者很難進行任何更改，那么開發人員就沒有動力在將來進行改進。

另一方面，審閱者有責任確保每個CL的質量都使得其代碼庫的整體代碼運行狀況不會隨著時間的流逝而減少。這可能很棘手，因為隨著時間的推移，代碼庫通常會由于代碼運行狀況的小幅下降而退化，尤其是當團隊處于明顯的時間限制下并且他們認為必須采取捷徑才能實現其目標時。

此外，審閱者對他們正在審閱的代碼擁有所有權和責任。他們希望確保代碼庫保持一致，可維護，以及“代碼審查中的查找內容”中提到的所有其他事項 。

因此，我們將以下規則作為代碼審查中期望的標準：

通常，即使CL并不完美，一旦處于肯定可以改善正在使用的系統的整體代碼運行狀況的狀態下，審閱者就應該批準它。

這是所有代碼審查指南中的高級原則。

當然，這是有局限性的。例如，如果CL添加了審閱者不希望在其系統中使用的功能，那么即使代碼設計得當，審閱者也可以肯定拒絕批準。

這里的關鍵點是，沒有“完美”的代碼，只有更好的代碼。審稿人不應要求作者在批準前拋光CL的每一小塊。相反，與他們所建議的更改的重要性相比，審閱者應該平衡取得進步的需要。審稿人要追求的不是持續追求完美，而是 持續改進?？傮w而言，可以提高系統的可維護性，可讀性和可理解性的CL不應延遲幾天或幾周，因為它不是“完美的”。

審閱者應該隨時發表評論，表示可能會更好，但是如果不是很重要，請在其前面加上“ Nit：”之類的字樣，以使作者知道這只是他們可以選擇忽略的亮點。

注意：本文檔中沒有任何理由證明檢查CL肯定會 惡化系統的整體代碼運行狀況。您唯一要做的是在緊急情況下。

指導

代碼審查具有重要的功能，可以教給開發人員有關語言，框架或通用軟件設計原理的新知識。留下有助于開發人員學習新知識的評論總是很好的。共享知識是隨著時間的推移改善系統代碼運行狀況的一部分。請記住，如果您的評論純粹是教育性的，但對滿足本文檔中描述的標準不是至關重要的，請在其前面加上“ Nit：”，否則，表明并非強制要求作者在此CL中對其進行解決。

原則

• 技術事實和數據否決了意見和個人喜好。
• 在樣式方面，樣式指南 是絕對權威。不在樣式指南中的任何純樣式點（空格等）都是個人喜好問題。樣式應與那里的樣式保持一致。如果沒有以前的樣式，請接受作者的樣式。
• 軟件設計方面幾乎從來都不是純粹的樣式問題，也不是個人喜好。它們基于基本原則，應權衡這些原則，而不僅僅是個人意見。有時有一些有效的選擇。如果作者可以證明（通過數據或基于可靠的工程原理）幾種方法同樣有效，那么審閱者應接受作者的偏愛。否則，選擇取決于軟件設計的標準原理。
• 如果沒有其他規則適用，則審閱者可以要求作者與當前代碼庫中的內容保持一致，只要這不會使系統的總體代碼運行狀況惡化。

解決沖突

在代碼審閱中發生任何沖突時，第一步應始終是使開發人員和審閱者根據本文檔以及《 CL作者指南》 和《審閱者指南》中其他文檔的內容達成共識。

當達成共識變得特別困難時，在審閱者和作者之間進行面對面的會議或VC可能會有所幫助，而不僅僅是嘗試通過代碼審閱注釋來解決沖突。（但是，如果這樣做，請確保將討論的結果記錄在CL上的注釋中，以備將來閱讀。）

如果那不能解決問題，則最常見的解決方法是升級。升級的途徑通常是進行更廣泛的團隊討論，其中包括TL的權衡，要求代碼維護者的決定或要求Eng經理提供幫助。不要讓CL坐下來，因為作者和審稿人無法達成協議。

在代碼審查中尋找什么

注意：在考慮這些要點時，始終確保考慮到 《代碼審查標準》。

設計

審查中最重要的內容是CL的總體設計。CL中各種代碼的交互是否有意義？此更改是屬于您的代碼庫還是屬于庫？它與系統的其余部分是否集成良好？現在是添加此功能的好時機嗎？

功能性

此CL是否達到開發人員的預期目的？開發人員打算為該代碼的用戶帶來什么好處？“用戶”通常既是最終用戶（當他們受到更改影響時）又是開發人員（將來他們將不得不“使用”此代碼）。

通常，我們希望開發人員能夠對CL進行良好的測試，以確保它們在進行代碼審查時能夠正常工作。但是，作為審閱者，您仍然應該考慮邊緣情況，尋找并發性問題，嘗試像用戶一樣思考，并確保沒有僅僅通過閱讀代碼就能看到的錯誤。

您可以根據需要驗證CL，對于審閱者來說，檢查CL的行為最重要的時間是對用戶產生影響，例如 UI更改。當您僅閱讀代碼時，很難理解某些更改將如何影響用戶。對于這樣的更改，如果過于麻煩而無法在CL中打補丁并自己嘗試，則可以讓開發人員為您提供功能演示。

在代碼審查期間考慮功能性的另一時間特別重要的是，CL中是否正在進行某種并行編程，從理論上講可能導致死鎖或競爭條件。僅通過運行代碼很難檢測到這類問題，通常需要有人（開發人員和審閱者）仔細考慮它們，以確保不會引入問題。（請注意，這也是在可能出現競爭條件或死鎖的情況下不使用并發模型的一個很好的理由，這會使進行代碼審查或理解代碼非常復雜。）

復雜

CL是否比應該的要復雜？在CL的每個級別都進行檢查-個別行是否太復雜？功能太復雜了嗎？類太復雜了嗎？“過于復雜”通常意味著“代碼閱讀器無法快速理解。”也可能意味著“開發人員在嘗試調用或修改此代碼時可能會引入錯誤。”

一種特殊類型的復雜性是過度設計，即開發人員使代碼變得比需要的通用，或者增加了系統目前不需要的功能。評論者應特別警惕過度設計。鼓勵開發人員解決他們現在需要解決的已知問題，而不是解決開發人員推測 將來可能需要解決的問題。未來的問題一到達就應該解決，您可以在物理宇宙中看到它的實際形狀和要求。

測驗

根據更改要求進行單元測試，集成測試或端到端測試。通常，除非CL處理緊急情況，否則應在與生產代碼相同的CL中添加測試 。

確保CL中的測試正確，合理且有用。測試不會自我測試，我們很少為測試編寫測試-人員必須確保測試有效。

代碼破損時，測試實際上會失敗嗎？如果代碼在其下面更改，它們將開始產生誤報嗎？每個測試都會做出簡單而有用的斷言嗎？測試是否在不同的測試方法之間適當地分開？

請記住，測試也是必須維護的代碼。不要僅僅因為它們不是主要二進制文件的一部分而接受測試中的復雜性。

命名

開發人員是否為所有事情都選擇了好名字？一個好名字足夠長，可以充分傳達物品的含義或作用，而又不會太長而難以閱讀。

評論

開發人員是否用可理解的英語寫下清晰的評論？所有評論實際上都是必要的嗎？通常，當注釋解釋了為什么存在某些代碼，而不應該解釋某些代碼在做什么時，它們很有用。如果代碼不夠清晰，無法解釋自身，則應使代碼更簡單。有一些例外情況（例如，正則表達式和復雜算法通常會從注釋中解釋它們的作用而受益匪淺），但大多數注釋是針對代碼本身可能無法包含的信息，例如決策背后的原因。

查看此CL之前的注釋也可能會有所幫助。也許有一個待辦事項現在可以刪除，有意見建議不要進行此更改，等等。

請注意，注釋與類，模塊或函數的文檔不同，注釋應表示一段代碼的用途，應如何使用以及使用時的行為。

樣式

我們風格指南在谷歌為我們所有的主要語言，甚至對于大多數小語種的。確保CL遵循適當的樣式指南。

如果您想改善樣式指南中沒有的樣式點，請在注釋前面加上“ Nit：”，以使開發人員知道這是您認為可以改善代碼但不是強制性的選擇。不要阻止僅根據個人風格偏好提交CL。

CL的作者不應將主要樣式更改與其他更改結合在一起。這使得很難看到CL中的更改，使合并和回滾更加復雜，并導致其他問題。例如，如果作者想要重新格式化整個文件，請他們僅將重新格式化的格式作為一個CL發送給您，然后再發送另一個具有功能更改的CL。

文獻資料

如果CL改變了用戶構建，測試，與代碼交互或釋放代碼的方式，請檢查其是否還更新了相關文檔，包括自述文件，g3doc頁面和任何生成的參考文檔。如果CL刪除或棄用了代碼，請考慮是否還應刪除該文檔。如果缺少文檔，請提出要求。

每條線

查看已分配給您檢查的每一行代碼。有時可以掃描諸如數據文件，生成的代碼或大型數據結構之類的東西，但不要掃描人工編寫的類，函數或代碼塊，并假設其中的內容是可以的。顯然，某些代碼比其他代碼更需要仔細檢查-這是您必須做出的判斷調用-但您至少應確保您了解所有代碼在做什么。

如果對您來說太難閱讀代碼了，這會使審查速度變慢，那么您應該讓開發人員知道這一點，并等待他們澄清，然后再嘗試審查。在Google，我們聘請了出色的軟件工程師，您就是其中之一。如果您聽不懂代碼，其他開發人員也很可能不會。因此，當您要求開發人員進行澄清時，您還可以幫助將來的開發人員理解此代碼。

如果您了解代碼，但又沒有資格進行部分審核，請確保在CL上有一位合格的審核員，特別是在復雜性問題（例如安全性，并發性，可訪問性，國際化等）上。

語境

在廣泛的背景下查看CL通常會很有幫助。通常，代碼查看工具只會向您顯示圍繞要更改的部分的幾行代碼。有時，您必須查看整個文件，以確保更改確實有意義。例如，您可能會看到僅添加了四行，但是當您查看整個文件時，您會看到這四行位于50行方法中，現在確實需要分解為較小的方法。

在整個系統的上下文中考慮CL也很有用。此CL是在改善系統的代碼運行狀況，還是使整個系統更加復雜，測試更少等？不要接受會降低系統代碼運行狀況的CL。大多數系統會通過許多小的更改而變得復雜，因此，重要的是要防止新更改中出現很小的復雜性。

好東西

如果您在CL中看到不錯的東西，請告訴開發人員，尤其是當他們以出色的方式回答了您的評論之一時。代碼審查通常只關注錯誤，但是他們也應該鼓勵和贊賞良好實踐。在指導方面，有時候告訴開發人員正確的做法比告訴他們錯誤的做法更有價值。

摘要

在進行代碼審查時，您應確保：

• 代碼經過精心設計。
• 該功能對代碼的用戶來說很好。
• UI的任何更改都是明智的，并且看起來不錯。
• 任何并行編程都是安全完成的。
• 代碼沒有比需要的復雜。
• 開發人員沒有實現他們將來可能需要的東西，但不知道他們現在需要什么。
• 代碼具有適當的單元測試。
• 測試經過精心設計。
• 開發人員對所有內容都使用了清晰的名稱。
• 注釋清晰而有用，并且大多數解釋了原因而不是原因。
• 代碼已正確記錄（通常在g3doc中）。
• 該代碼符合我們的樣式指南。

確保檢查要求檢查的每一行代碼，查看上下文，確保您在改善代碼運行狀況，并稱贊開發人員所做的出色工作。

瀏覽評論中的CL

摘要

現在您知道要查找的內容了，管理散布在多個文件中的審閱的最有效方法是什么？

1. 更改有意義嗎？它有一個很好的 描述嗎？
2. 首先看一下變化中最重要的部分。整體設計得好嗎？
3. 以適當的順序查看其余的CL。

第一步：全面了解變化

查看CL說明以及CL的一般功能。這種變化甚至有意義嗎？如果最初不應該進行此更改，請立即做出答復，說明為什么不應該進行更改。當您拒絕這樣的更改時，最好還是向開發人員建議他們應該做些什么。

例如，您可能會說：“看起來您為此做了一些出色的工作，謝謝！但是，實際上，我們正朝著刪除您在此處修改的FooWidget系統的方向發展，因此我們現在不希望對其進行任何新的修改。相反，您可以重構我們的新BarWidget類嗎？”

請注意，審閱者不僅拒絕當前的CL并提出其他建議，而且還禮貌地做到了。這種禮貌很重要，因為即使我們不同意，我們也想表明我們彼此尊重，作為開發人員。

如果獲得的多個CL代表您不想進行的更改，則應考慮重新設計團隊的開發流程或外部貢獻者的已發布流程，以便在編寫CL之前進行更多的溝通。最好在人們完成大量現在必須扔掉或徹底重寫的工作之前告訴他們“不”。

第二步：檢查CL的主要部分

查找屬于此CL的“主要”部分的文件。通常，一個文件的邏輯更改數量最多，這是CL的主要部分。首先看這些主要部分。這有助于為CL的所有較小部分提供上下文，并通常加快執行代碼審閱的速度。如果CL太大，您無法確定哪些部分是主要零件，請詢問開發人員您應該首先看什么，或要求他們 將CL分成多個CL。

如果您發現CL的這一部分存在一些主要的設計問題，則即使您現在沒有時間審查CL的其余部分，也應立即發送這些評論。實際上，復查CL的其余部分可能會浪費時間，因為如果設計問題足夠嚴重，那么正在復查的許多其他代碼都將消失并且無論如何都不會變得很重要。

立即發出這些主要設計評論非常重要有兩個主要原因：

• 開發人員通常會郵寄一個CL，然后在等待審核時立即基于該CL進行新工作。如果您正在審查的CL中存在重大設計問題，那么他們也將不得不重新設計其以后的CL。您希望在他們在有問題的設計之上進行過多額外工作之前就抓住他們。
• 重大的設計變更比小的變更需要更長的時間。開發人員幾乎都有截止日期；為了在截止日期之前完成工作，并在代碼庫中保留高質量的代碼，開發人員需要盡快開始CL的所有重大重做。

第三步：按適當順序瀏覽其余的CL

確認CL整體上沒有大的設計問題后，請嘗試找出邏輯順序來瀏覽文件，同時還要確保不要錯過對任何文件的審查。通常，在瀏覽了主要文件之后，按照代碼審查工具向您展示它們的順序瀏覽每個文件是最簡單的。有時在閱讀主要代碼之前先閱讀測試也是有幫助的，因為這樣您就可以知道更改應該做什么。

代碼審查速度

為什么代碼審查應該很快？

在Google，我們優化了一組開發人員可以一起生產產品的速度，而不是優化了單個開發人員可以編寫代碼的速度。個人發展的速度很重要，但并不像整個團隊的速度那么重要。

當代碼審查緩慢時，會發生幾件事：

• 整個團隊的速度下降。是的，對評論沒有快速回應的個人可以完成其他工作。但是，由于每個CL等待審查和重新審查，因此團隊其余成員的新功能和錯誤修復被延遲了幾天，幾周或幾個月。
• 開發人員開始抗議代碼審查過程。如果審閱者僅每隔幾天回答一次，但每次都要求對CL進行重大更改，那么這對于開發人員來說可能會令人沮喪且困難。通常，這表示為對審閱者的“嚴格”程度的抱怨。如果審閱者要求進行相同的實質性更改（確實可以改善代碼運行狀況的更改），但是每次開發人員進行更新時都做出快速響應，則抱怨會消失。實際上，大多數對代碼審查過程的抱怨都可以通過加快過程來解決。
• 代碼的健康狀況可能會受到影響。當審核緩慢時，允許開發人員提交的CL可能不盡如人意。緩慢的審核也會阻止代碼清理，重構和對現有CL的進一步改進。

代碼審查應該有多快？

如果您不在一項重點任務的中間，則應在代碼完成后不久進行代碼審查。

一個工作日是響應代碼檢查請求所需的最長時間（即第二天早上的第一件事）。

遵循這些準則意味著典型的CL應在一天之內進行多輪審核（如果需要）。

速度與中斷

有一次，個人速度的考慮勝過團隊速度。如果您正在處理諸如編寫代碼之類的重點任務，請不要打擾自己進行代碼檢查。研究表明，開發人員在中斷之后要花很長時間才能恢復到平穩的開發流程。因此，在編寫代碼時打擾自己實際上 對團隊來說要比讓其他開發人員稍等一會兒進行代碼審查更為昂貴。

而是，在您的工作中遇到一個斷點，然后再響應審閱請求。這可能是您當前的編碼任務完成時，午餐后，從會議返回，從微型廚房回來等時。

快速反應

當我們談論代碼審查的速度時，它是我們所關注的響應時間，而不是CL通過整個審查并提交所花的時間。整個過程在理想情況下也應該是快速的，但是對于個人的響應來說，比整個過程迅速發生更為重要。

即使有時需要很長時間才能完成整個審閱過程，在整個審閱 過程中獲得審閱者的快速響應也可以極大地緩解開發人員對“緩慢”代碼審閱的不滿。

如果您忙于在CL上進行全面審核時，仍然可以發送快速響應，以使開發人員知道何時可以獲取它，建議其他可能會更快響應的審閱者，或者 提供一些初步的廣泛評論。（注意：這都不意味著您即使發送這樣的響應也不應中斷編碼-在工作中的合理斷點處發送響應。）

重要的是，審閱者應花費足夠的時間進行審閱，以確保他們的“ LGTM”表示“此代碼符合我們的標準。” 但是，理想情況下，個人答復仍應是快速的。

跨時區評論

在處理時區差異時，請在他們仍在辦公室時嘗試與作者聯系。如果他們已經回家了，請嘗試確保您的審核完成，然后他們第二天才回到辦公室。

LGTM帶評論

為了加速代碼審核，在某些情況下，即使審核人員也將未解決的評論留在了CL上，審核人員仍應給予LGTM /批準。在以下情況之一時完成此操作：

• 審閱者有信心開發者將適當地解決所有審閱者的其余評論。
• 剩下的變化是輕微的，不具備由開發商來完成。

除非另有明確說明，否則審閱者應指定他們打算使用這些選項中的哪一個。

當開發人員和審閱者位于不同時區時，帶有注釋的LGTM特別值得考慮，否則開發人員將等待一整天才獲得“ LGTM，批準”。

大型CL

如果有人向您發送了一個如此大的代碼審查，您不確定何時可以有時間對其進行審查，通常的響應應該是要求開發人員 將CL拆分為多個相互構建的較小的CL。 ，而不必一次審查所有巨大的CL。這通常是可能的，并且對審閱者很有幫助，即使它需要開發人員進行其他工作。

如果不能將一個CL 分解為較小的CL，并且您沒有時間快速審查整個事情，那么至少要對CL的總體設計寫一些評論，然后將其發回給開發人員進行改進。作為審閱者，您的目標之一應該是始終解除開發人員的封鎖或使他們能夠迅速采取某種進一步的措施，而又不犧牲代碼的運行狀況。

隨著時間的推移，代碼審查的改進

如果您遵循這些準則，并且嚴格執行代碼審查，則應該發現整個代碼審查過程會隨著時間的流逝而越來越快。開發人員將了解健康代碼的要求，并從一開始就向您發送出色的CL，所需的審查時間越來越少。審閱者學會快速做出響應，并且不會在審閱過程中增加不必要的延遲。但是，不要在代碼審查標準或質量上做出讓步，以達到想象中的速度改進 -從長遠來看，這實際上不會使任何事情更快地發生。

緊急情況

在某些緊急情況下，CL必須非?？焖俚赝ㄟ^ 整個審核過程，并且質量準則將得到放寬。但是，請參閱什么是緊急情況？描述哪些情況實際上可以視為緊急情況，哪些不可以。

如何編寫代碼注釋

摘要

• 善待。
• 說明您的推理。
• 在給出明確的指示與指出問題并讓開發人員決定之間保持平衡。
• 鼓勵開發人員簡化代碼或添加代碼注釋，而不僅僅是向您解釋復雜性。

禮貌

通常，重要的是要禮貌和尊重，同時也要對要查看其代碼的開發人員非常清楚和有幫助。一種方法是確保您始終對代碼進行注釋，而永遠不要對開發人員進行注釋。您不必總是遵循這種做法，但是在說出可能會令人沮喪或引起爭議的內容時，一定要使用它。例如：

壞：“為什么顯然沒有從并發中獲得好處，為什么在這里使用線程？”

Good：“并發模型在這里增加了系統的復雜性，而我沒有看到任何實際的性能優勢。由于沒有任何性能上的好處，因此最好將此代碼為單線程而不是使用多個線程。”

解釋為什么

從上面的“好”示例中，您會注意到的一件事是，它可以幫助開發人員理解為什么要發表評論。您不一定總是需要在評論注釋中包含此信息，但是有時適當的做法是對您的意圖，所遵循的最佳實踐或您的建議如何改善代碼運行狀況進行更多說明。

提供指導

通常，修復CL是開發人員的責任，而不是審稿人的責任。您無需執行解決方案的詳細設計或為開發人員編寫代碼。

但是，這并不意味著審稿人應該沒有幫助。通常，您應該在指出問題和提供直接指導之間取得適當的平衡。指出問題并讓開發人員做出決定通?？梢詭椭_發人員學習，并使代碼審查更容易。這也可以帶來更好的解決方案，因為開發人員比審閱者更接近代碼。

但是，有時直接的指令，建議甚至代碼會更有幫助。代碼審查的主要目標是獲得最佳的CL。第二個目標是提高開發人員的技能，以便他們隨著時間的流逝需要越來越少的審查。

接受說明

如果您要求開發人員解釋一段您不理解的代碼，通常應使他們更清楚地重寫代碼。有時，在代碼中添加注釋也是一種適當的響應，只要它不只是解釋過于復雜的代碼即可。

僅在代碼檢查工具中編寫的說明對將來的代碼閱讀者沒有幫助。它們僅在某些情況下是可以接受的，例如，當您查看不十分熟悉的區域并且開發人員解釋了普通代碼讀者已經知道的內容時。

處理代碼審查中的推回

有時，開發人員會推遲進行代碼審查。他們要么會不同意您的建議，要么會抱怨您總體上過于嚴格。

誰是對的？

當開發人員不同意您的建議時，請先花點時間考慮一下它們是否正確。通常，它們比您更接近代碼，因此他們實際上可能對代碼的某些方面有更好的了解。他們的論點有意義嗎？從代碼健康角度來看，這有意義嗎？如果是這樣，請讓他們知道他們是對的，然后讓問題解決。

但是，開發人員并不總是正確的。在這種情況下，審稿人應進一步解釋為什么他們認為自己的建議正確。良好的解釋不僅說明了對開發人員回復的理解，而且還說明了為何要求進行更改的其他信息。

尤其是，當審閱者認為他們的建議將改善代碼的健康狀況時，如果他們認為所導致的代碼質量的改善證明所要求的其他工作是合理的，則他們應繼續倡導該更改。 改善代碼運行狀況的步驟往往很短。

有時，在真正提出建議之前，需要花幾輪的時間來解釋建議。請確保始終保持禮貌，并讓開發人員知道您聽到他們在說什么，您只是不同意。

煩人的開發人員

審稿人有時認為，如果審稿人堅持要改進，開發人員會感到沮喪。有時，開發人員確實會感到不高興，但這通常是簡短的，后來他們非常感謝您幫助他們提高了代碼質量。通常，如果您對您的評論彬彬有禮，那么開發人員實際上根本不會感到煩惱，而擔心只是在審閱者的腦海中。煩惱通常與注釋的編寫方式有關 ，而不是與審閱者對代碼質量的堅持有關。

稍后清理

回退的一個常見原因是開發人員（可以理解）想要完成任務。他們不想僅僅為了獲得此CL而進行另一輪審核。因此，他們說他們將在以后的CL中清理某些內容，因此您現在應該LGTM 此CL。一些開發人員對此非常好，并會立即編寫后續的CL來解決此問題。但是，經驗表明，開發人員在編寫原始CL之后花費的時間越多，清理工作的可能性就越小。實際上，通常除非開發人員立即進行清理在當前的CL之后，它永遠不會發生。這不是因為開發人員不負責任，而是因為他們有很多工作要做，并且清理工作在其他工作中被遺忘或遺忘。因此，通常最好是堅持要求開發人員在代碼進入代碼庫并“完成”之前立即清理其CL 。讓人們“稍后清理”是代碼庫退化的一種常見方法。

如果CL引入了新的復雜性，除非是緊急情況，否則必須在提交之前將其清除。如果CL暴露了周圍的問題，并且現在無法解決，則開發人員應提交清理錯誤并將其分配給自己，以免丟失。他們還可以選擇在引用已提交錯誤的代碼中編寫TODO注釋。

有關嚴格性的一般投訴

如果您以前對代碼的審查松懈，而轉而對代碼進行嚴格的審查，那么一些開發人員將大聲抱怨。提高代碼審查的 速度通常會使這些抱怨消失。

有時，這些抱怨可能要花費數月的時間才能消失，但是最終，開發人員往往會看到嚴格的代碼審查的價值，因為他們會看到自己幫助生成的出色代碼。有時候，一旦發生某種事情，使聲音最強烈的抗議者甚至成為您最堅強的支持者，這會使他們真正地通過嚴格地看待您所增加的價值。

解決沖突

如果您遵循上述所有內容，但是仍然遇到無法解決的開發人員之間的沖突，請參閱 《標準代碼審查》以獲取有助于解決沖突的準則和原則。