本文譯自Google最新開放的code review指南：How to do a code review
原文地址：https://google.github.io/eng-practices/review/reviewer/
該文檔一共分爲如下六篇：
- Code Review的標準
- Code Review關注點
- CL閱讀指南
- Code Review 的速度
- 如何編寫Code Review 評語
- 處理pushback
一、 Code review的標準
Code review 的主要目的是確保Google代碼庫的整體代碼運行狀況隨着時間的推移而得到改善。Code review的所有工具和流程都是爲此而設計的。
爲了實現這一目標，必須綜合考慮許多因素，並做出取捨和平衡。
首先，開發人員必須能夠在任務上取得進展。如果你從不向代碼庫提交改進後的代碼，那麼代碼庫就永遠不會得到改進。另外，如果一個reviewer使任何更改都很難進行，那麼開發人員就不願意在將來進行改進。
另一方面，reviewer有責任確保每個CL(Change Log)具有這樣的質量，即隨着時間的推移，其代碼庫的整體代碼健康狀況不會降低。這可能很棘手，因爲代碼庫通常會隨着時間的推移而降低代碼運行狀況，特別是當團隊的交付受到嚴重的時間限制，並且他們覺得必須採取捷徑才能實現目標時。
此外，reviewer對他們正在審覈的代碼擁有所有權和責任。他們希望確保代碼庫保持一致，可維護以及“code review中要注意的內容”中提到的所有其他內容。
因此，我們將以下規則作爲我們在code review中期望的標準：
一般來說，如果一個 CL並不完美，但是它肯定會提高當前系統的代碼整體健康度，那reviewer就應該讓它通過。
這是所有code review指南中的首要原則。
當然，這是有侷限性的。例如，如果一個CL添加了一個reviewer不希望在其系統中使用的功能，即使代碼設計得很好，reviewer也可以拒絕批准該CL。
這裏的一個關鍵點是，沒有“完美”的代碼，只有更好的代碼。Reviewer不應該要求開發人員對CL的每一個微小的部分進行打磨。相反，reviewer應該在項目的進展和reviewer的改進建議兩者之間做好權衡。Reviewer不應該追求完美，而應該追求持續的改進。作爲一個整體，提高系統可維護性、可讀性和可理解性的CL不應該因爲它不是“完美的”而延遲幾天或幾周通過審批。
如果有些東西可以做得更好，reviewer 應該隨時留下評論。但是如果該評論所建議的改進不是很重要，可以在前面加上“Nit:”這樣的前綴，讓作者知道這種改進只是一種錦上添花的效果，作者可以選擇忽略。
注意：本文檔中沒有任何內容推薦合入會明顯惡化系統的整體代碼健康狀況的CL。只有在緊急情況下你纔會那樣做。
指導思想
Code review的一個重要功能是教授開發人員關於語言、框架或一般軟件設計原則的新知識。留下幫助開發人員學習新東西的評論總是好的。隨着時間的推移，共享知識是改善系統代碼健康狀況的一部分。請記住，如果您的評論純粹是教育性的，但對於滿足本文檔中描述的標準並不是至關重要的，那麼在它前面加上“Nit:”，或者以其他方式表明並不強制作者在本CL中解決它。
原則
技術事實和數據優先於意見和個人偏好。
在風格問題上，以風格指南爲準則。任何風格指南中沒有規定的純樣式點(空格等)都是個人偏好的問題。這些點原則上應該與現有的風格保持一致。但是如果這些點現在還沒有形成一定的風格，那reviewer應該接受作者的風格。
軟件設計的各個方面幾乎從來不是純粹的風格問題，也不只是個人偏好。它們是建立在基本原則的基礎上的，應該在這些原則的基礎上加以衡量，而不僅僅是隻考慮個人意見。有時，如果作者能夠證明(通過數據或基於可靠的工程原理)幾種方法是同樣有效的，那麼reviewer應該接受作者的偏好。否則，reviewer的選擇取決於軟件設計的標準原則。
如果沒有其他規則適用，那麼reviewer可能會要求作者與當前代碼庫中的內容保持一致，只要這不會惡化系統的整體代碼健康狀況。
解決衝突
在對代碼評審的任何衝突中，開發人員和reviewer應該始終根據本文檔的內容以及“CL Author 's Guide“和“Reviewer Guide”中的其他文檔，嘗試達成一致意見。
當達成一致意見變得特別困難時，在reviewer和作者之間進行面對面的會議或VC(譯者注：不知道是什麼的縮寫)將會有所幫助，而不是僅僅試圖通過code revier評論來解決衝突。(不過，如果您這樣做了，請確保將討論結果記錄在CL的評論中，以供將來的讀者參考。)
如果這不能解決問題，最常見的解決方法就是升級。升級路徑通常是更廣泛的團隊討論，讓TL參與進來，請求代碼維護人員作出決策，或者請求Eng經理提供幫助。不要因爲作者和審稿人不能達成一致意見而讓CL無所事事。
二、 Code review關注點
注意：在考慮這些要點時，請務必同時參考“Code review的標準”。
設計
Code review 評論最重要的內容是CL的總體設計。CL中不同代碼段之間的交互有意義嗎?這個更改屬於您的代碼庫，還是屬於庫?它與系統的其他部分集成得好嗎?現在是添加此功能的恰當時機嗎?
功能
這個CL是否達到了開發人員的目的?開發人員的意圖對這段代碼的用戶有好處嗎?“用戶”通常是終端用戶(當他們受到更改的影響時)和開發人員(將來必須“使用”這些代碼)。
大多數情況下，我們希望開發人員能夠很好地測試CLs，以便在進行codereview時代碼能夠正確地工作。然而，作爲reviewer，您仍然應該考慮一些邊界情況，尋找併發性問題，嘗試像用戶一樣思考問題，並確保不會看到僅通過閱讀代碼就能發現的錯誤。
如果您願意，您可以對CL進行驗證—檢查CL行爲最重要的時間是當它具有面向用戶的影響時，例如UI更改。當您僅僅閱讀代碼時，很難理解一些更改將如何影響用戶。對於這樣的更改，如果不方便在CL中進行修補並親自嘗試，您可以讓開發人員提供功能的演示。
在代碼評審過程中考慮功能的另一個特別重要的時刻是，在CL中是否存在某種併發編程，這理論上可能會導致死鎖或競爭條件。僅通過運行代碼很難發現這類問題，通常需要有人(開發人員和review)仔細考慮這些問題，以確保沒有引入問題。(注意，這也是一個不使用可能存在競爭條件或死鎖的併發模型的好理由——這會使code review或理解代碼變得非常複雜。)
複雜性
CL比它應該的複雜嗎?在cl的每一層檢查這個—單個行是不是太複雜了?函數是否過於複雜?類太複雜了嗎?“太複雜”通常意味着“代碼讀者不能很快理解”。這也意味着“當開發人員試圖調用或修改這段代碼時，他們很可能會引入bug。”
一種特殊類型的複雜性是過度設計，開發人員使代碼比需要的更通用，或者增加了系統目前不需要的功能。reviewer應該特別警惕過度設計。鼓勵開發人員解決他們知道現在需要解決的問題，而不是解決開發人員推測將來可能需要解決的問題。未來的問題應該在它到來後解決，你可以看到它在物理宇宙中的實際形狀和需求。
測試
根據更改要求進行單元測試、集成測試或端到端測試。一般來說，測試應該添加到與生產代碼相同的CL中，除非CL正在處理緊急情況。
確保CL中的測試是正確的、合理的和有用的。測試本身不進行測試，而且我們很少爲我們的測試編寫測試—人類必須確保測試是有效的。
當代碼有問題時，測試會真的失敗嗎?如果下面的代碼發生變化，它們會開始產生假陽性嗎?每個測試都做出簡單而有用的斷言嗎?測試是否在不同的測試方法之間適當地分開?
請記住，測試也是必須維護的代碼。不要僅僅因爲測試不是主分支的一部分就接受測試中的複雜性。
命名
開發人員是否爲所有東西都選擇了好名字?一個好的名字應該足夠長，從而可以充分地表達條目是什麼或做了什麼，並且不會長到讓人難以閱讀。
註釋
開發人員是否用可理解的英語編寫了清晰的註釋?所有的評論都是必要的嗎?通常，註釋在解釋某些代碼爲什麼存在時很有用，而不應該解釋某些代碼在做什麼。如果代碼不夠清晰，無法達到自解釋，那麼應該簡化代碼。也有一些例外(例如，解釋正則表達式和複雜算法在做什麼通常幫助很大)，但大多數註釋是針對代碼本身不可能包含的信息，比如決策背後的推理。
查看CL之前的評論也會很有幫助。也許現在有一個可以刪除的待辦事項，一個建議不要做這個更改的評論，等等。
注意，註釋不同於類、模塊或函數的文檔，這些文檔應該表示代碼的用途、應該如何使用以及使用時的行爲。
風格
我們爲Google提供所有主要語言的風格指南，甚至包括大多數小衆語言。確保CL遵循適當的樣式指南。
如果你想改進樣式指南中沒有涉及的一些樣式點，請在評論前加上“Nit：”，讓開發人員知道你認爲這會改善代碼，但不是強制性的。不要僅根據個人風格偏好阻止提交CL。
CL的作者不應將大量樣式更改和代碼更改放在一起提交。它使得很難看到CL中的代碼更改，使合併和回滾更復雜，並導致其他問題。例如，如果作者想要重新格式化整個文件，讓他們只將重新格式化爲一個CL，然後再發送另一個CL及其功能更改。
文檔
如果CL更改了用戶構建、測試、交互或發佈代碼的方式，請檢查它是否還更新了相關文檔，包括READMEs、g3doc頁面和任何生成的參考文檔。如果CL刪除或棄用代碼，請考慮是否也應該刪除文檔。如果缺少文檔，就去問作者要。
每一行
查看分配給您的每一行代碼。有些東西，比如數據文件、生成的代碼或大型數據結構，您有時可以大致瀏覽一下，但是由人編寫的類、函數或代碼塊不能粗略的瀏覽，並假定其中的內容是正確的。顯然，有些代碼需要比其他代碼檢查的更仔細—這是您必須做出的判斷—但是您至少應該確保您理解所有代碼在做什麼。
如果這段代碼您閱讀起來比較費勁，並且會減慢評審的速度，那麼您應該讓開發人員知道這一點，並在您嘗試評審之前等待他們澄清它。在谷歌，我們僱傭優秀的軟件工程師，你就是其中之一。如果您不能理解代碼，其他開發人員也很可能無法理解。因此，當您要求開發人員澄清這些代碼時，您也在幫助未來的開發人員理解這些代碼。
如果您理解所review的代碼，但是您覺得不能勝任這次review，那麼請確保針對這個CL有一個合格的review，特別是對於複雜的問題，比如安全性、併發性、可訪問性、國際化等等。
上下文
在廣泛的上下文中查看CL通常是有幫助的。一般地，code review工具只會顯示正在更改的部分周圍的幾行代碼。有時您必須查看整個文件，以確保更改實際上是有意義的。例如，您可能只看到添加了四行，但是當您查看整個文件時，您會看到這四行位於一個50行方法中，現在確實需要將其分解爲更小的方法。
在整個系統的上下文中考慮CL也很有用。這個CL是提高了系統的代碼健康度，還是使整個系統更復雜、測試更少等等?不要接受降低系統代碼健康度的CLs。大多數系統都是通過許多累積起來的小更改而變得複雜的，因此，即使是防止在新更改中引入很小的複雜性也是很重要的。
處理CL中好的方面
如果您在CL中看到一些不錯的東西，請告訴開發人員，特別是當他們以一種很好的方式處理您的一條評論的改進建議。Code review通常只關注錯誤，但是它們也應該爲好的實踐提供鼓勵和讚賞。有時候，在指導方面，告訴開發人員他們做對了什麼比告訴他們他們做錯了什麼更有價值。
總結
在code review過程中你應確保:
代碼設計得很好。
該功能對代碼的用戶（開發人員以及系統的用戶）有益。
任何UI更改都是合理的，看起來也不錯。
任何併發編程都是安全的。
代碼並不比它需要的複雜。
開發人員沒有實現他們將來可能需要但不知道現在是否需要的東西。
代碼有適當的單元測試。
單元測試是精心設計過的。
開發人員在代碼中的所有命名都是清晰的。
註釋清晰有用，主要解釋爲什麼而不是解釋是什麼。
代碼被合適地文檔化了(通常在g3doc中)。
代碼符合我們的樣式指南。
確保檢查您被要求檢查的每一行代碼，查看上下文，確保您正在改進代碼的健康狀況，並讚揚開發人員做的好的地方。
三、 CL閱讀指南
摘要
既然您知道“Code review關注點”，那麼管理跨多個文件的codereview的最有效方法是什麼?
這種變化有意義嗎? CL(change log)的描述清晰明瞭嗎?
首先看看CL中最重要的部分。CL的整體設計好嗎?
按照適當的順序查看CL的其餘部分。
第一步:從全局的視角看下CL
看看CL的描述，以及CL大概做了什麼。CL涉及的變更有意義嗎?如果這個變更一開始就不應該發生，請立即回覆並解釋爲什麼不應該發生變更。當您拒絕這樣的變更時，最好也向開發人員建議他們應該做什麼。
例如，你可以說“看起來你在這方面做得不錯，謝謝!”不過，我們實際上準備刪除你在修改的FooWidget系統，所以我們現在不想對它做任何新的修改。你不如來重構我們的新BarWidget類?”
注意，review不僅要在拒絕了當前的CL時提供一個替代的建議，而且很有禮貌的拒絕。這種禮貌是很重要的，因爲我們想要表現出即使我們意見不一致，我們作爲開發人員也彼此尊重。
如果您發現出現多個你不希望進行更改的CLs，那麼您應該重新考慮一下團隊的開發流程或外部貢獻者發佈的流程，以便在他們編寫CLs之前跟你有更多的溝通。最好在人們完成大量工作之前就說“不”，這些工作現在必須扔掉或徹底重寫。
第二步：檢查CL的主要部分
找出這個CL的“主要”部分，CL的主要部分一般是一個或者幾個文件。通常，只有一個文件具有最多的邏輯更改，它是CL的主要部分。首先看看這些主要部分。這有助於爲CL的所有較小部分提供上下文，並且通常這會加速代碼評審。如果CL太大，您無法確定哪些部分是主要部分，請詢問開發人員應該首先查看什麼，或者讓他們將CL分割成多個CLs。
如果您看到CL的這一部分存在一些主要的設計問題，您應該立即給出反饋，即使您現在沒有時間來檢查CL的其餘部分。事實上，檢查CL的其餘部分可能是浪費時間，因爲如果設計問題足夠嚴重，那麼許多其他正在檢查的代碼後面可能會刪掉或者重構，不管怎樣都無關緊要。
如果主要設計有缺陷，立即給出反饋非常重要，有兩個主要原因：
開發人員通常會提交一個CL，然後在等待評審時立即基於該CL開始新的工作。如果您正在檢查的CL中存在主要的設計問題，那麼他們還必須重新編寫後面的CL。您應該在它們在有問題的設計上做過多額外工作之前阻止它們。
大的設計變更比小的變更需要更長的時間。開發人員的任務幾乎都有截止日期;爲了在代碼庫中保持高質量代碼的同時在這些截止日期前完成任務，開發人員需要儘快開始對CL主要問題進行修改。
第三步：以適當的順序查看CL的其餘部分
一旦你確認整個CL沒有重大的設計問題，試着找出一個邏輯序列來查看這些文件，同時確保你不會漏看任何文件。通常在查看主要文件之後，最簡單的方法是按照代碼審查工具向您提供的順序瀏覽每個文件。有時在閱讀主代碼之前先閱讀測試也很有幫助，因爲這樣你就可以瞭解CL做了什麼。
四、 Code review 的速度
爲什麼code review 要快？
在谷歌中，我們針對開發團隊共同開發產品的速度進行優化，而不是針對單個開發人員編寫代碼的速度進行優化。個人發展的速度很重要，但是沒有整個團隊的速度重要。
當code review很慢時，會發生以下幾件事：
整個團隊的速度降低了。如果一個人對評審的反應不是很快，他雖然在這期間做了一些其他的工作，但是，由於每個CL都要等待一次又一次的評審，團隊其他成員的新特性和bug修復會延遲幾天、幾周或幾個月。
開發人員開始抗議code review過程。如果reviewer每隔幾天纔回復一次，但每次都要求對CL進行重大更改，這對開發人員來說可能是令人沮喪和困難的。通常，這表現爲對reviewer的“嚴格”的抱怨。如果reviewer請求相同的實質性更改(這些更改確實改善了代碼的健康狀況)，但是每次開發人員進行更新時都會快速響應，那麼抱怨就會消失。對代碼評審過程的大多數抱怨實際上是通過加快過程來解決的。
代碼健康狀況會受到影響。當評審速度較慢時，允許開發人員提交不如預期的CLs的壓力就會增加。緩慢的評審還會阻礙代碼清理、重構和對現有CLs的進一步改進。
代碼評審應該有多快？
如果您沒有集中精力完成任務，那麼應該在任務完成後不久進行代碼檢查。
一個工作日是響應代碼審查請求所需的最長時間（即第二天早上的第一件事）。
遵循這些指導原則意味着一個典型的CL應該在一天內(如果需要的話)進行多輪評審。
速度與中斷
有一段時間，對個人速度的考慮超過了對團隊速度的考慮。如果你正在集中精力做一項任務，比如寫代碼，不要打斷自己去做codereview。研究表明，開發人員在中斷開發之後，可能需要很長時間才能恢復到平穩的開發流程。因此，對團隊來說，在編寫代碼時打斷自己實際上比讓另一個開發人員等待code review的時間更昂貴。
相反，在你的工作中等待一個斷點，然後你纔回應一個審查的請求。這可能是當你當前的編碼任務完成時，午飯後，從會議回來，從微型廚房回來，等等。
快速反應
當我們討論代碼評審的速度時，我們關心的是響應時間，而不是CL完成整個評審並提交所需的時間。理想情況下，整個過程也應該是快速的，但是對於單個響應的快速響應比整個過程的快速響應更重要。
即使有時需要很長時間才能完成整個評審過程，但是在整個過程中reviewer的快速響應可以極大地減輕開發人員對“緩慢”code review的沮喪。
如果在一個CL提交過來時，你太忙了,難以做一個完整的review,你仍然可以發送一個快速反應,讓開發人員知道什麼時候你會開始review,建議由其他reviewer來評審可以更快地響應的效果,或者提供一些最初的粗略評論。(注意:這並不意味着您應該中斷編碼，即使是爲了發送這樣的響應—也應該在您工作中的一個合理的斷點發送響應。)
重要的是reviewer要花足夠的時間進行評審，以確保他們的“LGTM”的意思是“這段代碼符合我們的標準”。然而，個人的反應最好還是要快。
跨時區評論
當處理時區差異時，試着在作者還在辦公室的時候給出迴應。如果他們已經回家了，那麼在他們第二天回到辦公室之前，確保你的評估已經完成。
LGTM評論
爲了加快code review的速度，在某些情況下，reviewer應該給出LGTM/Approval，即使他們還在CL上留下未解決的註釋。這是在以下兩種情況下完成的:
reviewer確信開發人員將適當地處理reviewer剩餘的所有評論。
其餘的更改是次要的，開發人員不一定非要完成。
如果不清楚，reviewer應該指定他們想要的選項。
當開發人員和reviewer處於不同的時區時，使用帶有註釋的LGTM尤其值得考慮，否則開發人員將會等待一整天，只爲獲得“LGTM，批准”。
大型CLs
如果有人給你提交了一個非常大的CL，你不知道什麼時候你能有時間去review它,你的典型的反應應該要求開發人員把CL分割成幾個較小的CLs,而不是一個巨大的CL必須一次性審查。這通常是可行的，並且對reviewer非常有幫助，即使這需要開發人員做額外的工作。
如果CL無法分解爲較小的CL，並且您沒有時間快速查看整個內容，那麼至少要對CL的整體設計寫一些評論並將其發送回開發人員以進行改進。作爲reviewer，您的目標之一應該是始終取消阻止開發人員或使他們能夠快速採取某種進一步的操作，而不會犧牲代碼運行狀況。
Code review隨時間的改進
如果您遵循這些指導原則，並且對code review非常嚴格，那麼您應該會發現，隨着時間的推移，整個code review過程會變得越來越快。開發人員瞭解健康代碼需要什麼，並從一開始就向您發送非常棒的CLs，這使得需要的評審時間越來越少。reviewer學會快速響應，而不是在評審過程中添加不必要的延遲。但是不要爲了提高速度而犧牲code review標準或質量——從長遠來看，這實際上不會使任何事情發生得更快。
緊急情況
在一些緊急情況下，CLs必須非常快速地通過整個評審過程，並且不會嚴格按照質量指南來要求它。但是，請看看什麼是緊急情況?用於描述哪些情況實際上符合緊急情況，哪些不符合緊急情況。
五、 如何編寫code review 評語
摘要
對人友善
解釋你的觀點
在給出明確的指示與指出問題並讓開發人員決定之間保持平衡。
鼓勵開發人員簡化代碼或添加代碼註釋，而不僅僅是向您解釋複雜性
禮貌
一般來說，禮貌和尊重是很重要的。並且您也要對review對象非常明瞭和有幫助。一種方法是確保您總是對代碼進行評論，而從不對開發人員進行評論（譯者注：對事不對人）。你不必總是遵循這個習慣，但是當你說一些可能會讓人心煩意亂或有爭議的話時，你絕對應該使用這個習慣。例如:
反例:“爲什麼您在這裏使用線程，但是沒有從併發中獲得任何好處?”
正例:“這裏的併發模型增加了系統的複雜性，但我看不到任何實際的性能優勢。因爲沒有性能上的好處，所以這段代碼最好是單線程的，而不是使用多線程。”
解釋爲什麼
關於上面的正面示例，您將注意到的一件事是，它幫助開發人員理解您爲什麼要發表評論。您並不總是需要在評審註釋中包含這些信息，但是有時候，對於您的意圖、您所遵循的最佳實踐，或者您的建議如何改進代碼健康狀況，給出更多的解釋是合適的。
提供指導
一般來說，修復CL是開發人員的責任，而不是review的責任。您不需要爲開發人員提供解決方案的詳細設計或編寫代碼。
不過，這並不意味着review應該毫無幫助。一般來說，你應該在指出問題和提供直接指導之間取得適當的平衡。指出問題並讓開發人員做出決策通常有助於開發人員學習，並使code review變得更容易。它還可以產生更好的解決方案，因爲開發人員比reviewer更接近代碼。
但是，有時直接的指令，建議甚至代碼會更有幫助。Code review的主要目標是獲得最佳的CL。第二個目標是提高開發人員的技能，以便他們隨着時間的流逝需要越來越少的審查。
接受解釋
如果您要求開發人員解釋一段您不理解的代碼，這通常會幫助他們更清楚地重寫代碼。偶爾，在代碼中添加註釋也是一種適當的響應，只要它不只是解釋過於複雜的代碼。
僅在code review工具中編寫的解釋對將來的代碼讀者沒有幫助。它們只在少數情況下是可接受的，例如當您正在review一個您不太熟悉的區域，並且開發人員僅僅解釋了一些代碼的顯而易見的內容時。
六、 處理回退
有時開發人員會抵制code review。要麼他們不同意你的建議，要麼他們會抱怨你總體上過於嚴格。
誰是對的？
當開發人員不同意您的建議時，請先花點時間考慮一下它們是否正確。 通常，開發人員比您更接近代碼，因此可能實際上他們對代碼的某些方面比您更瞭解一些。 他們的論點有意義嗎？ 從代碼健康角度來看，這有意義嗎？ 如果是這樣，請讓他們知道他們是對的，然後解決問題。
然而，開發人員並不總是正確的。在這種情況下，reviewer應該進一步解釋爲什麼他們認爲他們的建議是正確的。一個好的解釋不僅說明了對開發人員的回答的理解，也說明了爲什麼開發人員需要做出更改的附加信息。
特別是，當reviewer認爲他們的建議將改善代碼的健康狀況時，如果他們認爲所產生的代碼質量改進能夠證明所要求的額外工作是合理的，那麼他們應該繼續提倡更改。改善代碼健康狀況往往是一些小步驟。
有時候，爲了讓開發人員真正理解您的一個建議之前，您需要花幾輪時間來解釋它。您只要確保始終保持禮貌，並讓開發人員知道您聽到了他們在說什麼，您只是不同意。
令開發人員不安
reviewer有時認爲，如果自己堅持要進行改進，開發人員會感到不安。有時候開發人員確實會感到沮喪，但是這通常是很短暫的，之後他們會非常感謝您幫助他們提高了代碼的質量。通常，如果您在評論中表現得很有禮貌，開發人員實際上一點也不會感到不安，而這種擔心只存在於您的腦海中。通常，令人不安的地方更多的是評論的編寫方式，而不是reviewer對代碼質量的堅持。
稍後清理
回退的一個常見原因是開發人員（可以理解）想要完成任務。 他們不想僅僅爲了獲得此CL而進行另一輪審覈。因此，他們說他們將在以後的CL中清除某些內容，因此您現在應該LGTM此CL。 一些開發人員對此非常好，並會立即編寫後續的CL來解決此問題。 但是，經驗表明，開發人員在編寫原始CL之後花費的時間越多，清理工作的可能性就越小。 實際上，通常除非開發人員在當前CL之後立即進行清理，否則它永遠不會發生。 這不是因爲開發人員不負責任，而是因爲他們有很多工作要做，而清理工作卻在其他工作中被遺忘或遺忘。 因此，通常最好是堅持要求開發人員在代碼進入代碼庫並“完成”之前立即清理其CL。讓人們“稍後清理”是代碼庫退化的一種常見方法。
如果CL引入了新的複雜性，在提交之前必須清理它，除非是緊急情況。如果CL暴露了周圍的問題，而這些問題現在還無法解決，開發人員應該爲清理工作提交一個bug文件，並將其分配給自己，這樣它就不會丟失。他們還可以選擇在引用已歸檔錯誤的代碼中編寫TODO註釋。
對嚴格的普遍抱怨
如果您以前有相當鬆散的代碼評審，而現在您轉而進行嚴格的評審，那麼一些開發人員將會非常大聲地抱怨。提高代碼評審的速度通常會使這些抱怨逐漸消失。
有時，這些抱怨可能要花費數月的時間才能消失，但是最終，開發人員往往會看到嚴格的代碼審查的價值，因爲他們會看到自己幫助生成的出色代碼。 有時，一旦發生某種事情，使嚴格的抗議者甚至成爲您最堅強的支持者，這會使他們真正地看到自己在增加的價值。
解決衝突
如果您遵循上述所有方法，但是您仍然遇到您自己和開發人員之間無法解決的衝突，請參閱代碼評審標準，瞭解有助於解決衝突的指導原則和原則。