程式碼評審標準

程式碼評審的主要目的是確保 Google 程式碼庫的整體程式碼執行狀況隨著時間的推移而不斷改善。程式碼評審的所有工具和過程都是為此設計的。

為了實現這一點，必須做出一系列的權衡。

首先，開發人員必須能夠在其任務上取得進展。如果開發人員從未向程式碼庫提交過改進，那麼程式碼庫將永遠不會得到改善。另外，如果評審人員不進行任何更改，那麼之後開發人員也沒有動力進行改進。

另一方面，評審人員有責任確保每個 CL（變更列表）的質量，使得其程式碼庫的整體程式碼執行狀況不會隨著時間的流逝而減少。這可能很棘手，因為隨著時間的推移，程式碼庫通常會由於程式碼執行狀況的小幅下降而退化，尤其是在開發團隊時間緊迫，認為必須採取捷徑才能實現其目標的情況下。

此外，評審人員對他們正在評審的程式碼要負起責任。確保程式碼庫保持一致性和可維護性，以及“程式碼評審中的查詢內容”中提到的其他事項 。

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

通常，即使 CL 並不完美，不過如果達到可以提升系統整體程式碼質量的程度，評審人員就可以批准它。

這是所有程式碼評審指南中的最高原則。

當然，是有例外的。例如，如果 CL 新增了評審人員不希望在其系統中使用的功能，那麼即使程式碼設計得當，評審人員也可以肯定的拒絕批准。

這裡的關鍵點是，沒有“完美”的程式碼，只有更好的程式碼。評審人員不應要求開發人員在批准前拋光 CL 的每一小塊細節。評審人員要追求的不應該是完美，而應該是持續改進。總體而言，如果一個 CL 可以提高系統的可維護性，可讀性和可理解性，那就不應該因為它不是“完美的”而被延遲幾天甚至幾周。

評審人員應該隨時提供建議，這樣開發人員可能會做得更好，但是如果不是很重要的建議，可以在其前面加上“ Nit：”之類的字眼，以使開發人員知道這只是一個改進建議，他們可以選擇忽略。

指導

程式碼評審具有重要的功能，可以傳授開發人員關於語言，框架或通用軟體設計原理的新知識。隨著時間的推移共享知識會成為改善系統程式碼執行質量的一部分。但要注意，如果你的建議純粹是帶有教育性質的，並且對於滿足本文所描述的標準來說並不是那麼重要，那麼請在前面加上“Nit:”，或者以其他方式告訴開發人員，他們並不一定要在 CL 中解決這些問題。

原則

• 客觀的技術和資料比個人意見和偏好更重要。
• 在程式碼風格方面，樣式指南是絕對權威。不在樣式指南中的任何純樣式點（空格等）都是個人喜好問題。樣式應與那裡的樣式保持一致。如果沒有以前的樣式，請接受作者的樣式。
• 軟體設計方面從來都不是純粹的樣式問題，也不是個人喜好。它們基於基本原則，應權衡這些原則，而不僅僅是個人意見。有時有一些有效的選擇。如果開發 人員可以證明（通過資料或基於可靠的工程原理）幾種方法同樣有效，那麼評審人員應接受開發人員的選擇。否則就應該基於軟體設計標準原則做出決定。
• 如果沒有其他的適用規則，那麼評審人員可以要求開發人員與當前程式碼庫中的內容保持一致，只要不會使系統的總體程式碼執行狀況惡化就可以。

解決衝突

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

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

如果還不能解決問題，那麼就要考慮把問題升級。升級的途徑通常是進行更廣泛的團隊討論，其中包括讓團隊負責人蔘與進來，請求程式碼維護人員作出決定，或請求工程經理提供幫助。不要因為開發人員和評審人員無法達成一致意見就讓 CL 一直掛在那裡。

程式碼評審中的查詢內容

設計

程式碼評審中最重要的部分是 CL 的總體設計。CL 中各種程式碼的互動是否有意義？此更改是屬於程式碼庫還是屬於某個包？它與系統的其餘部分是否整合良好？現在是新增此功能的好時機嗎？

功能性

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

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

您可以根據需要驗證 CL，對於評審人員來說，檢查 CL 的行為最好的時機是當它對使用者產生了影響，例如 UI 更改。當只是閱讀程式碼的時候，很難理解一些更改將如何影響使用者。對於這樣的更改，如果過於麻煩而無法在 CL 中打補丁並自己嘗試，則可以讓開發人員提供功能演示。

在程式碼評審期間考慮功能性的另一個時機點是，CL 中是否正在進行某種並行程式設計，從理論上講可能導致死鎖或競爭條件。僅通過執行程式碼很難檢測到這類問題，通常需要有人（開發人員和評審人員）仔細考慮它們，以確保不會引入問題。

複雜性

CL 是否比實際需要的要複雜？在 CL 的每個級別都進行檢查 —— 個別行是否太複雜？功能太複雜？類太複雜？“過於複雜”通常意味著“程式碼閱讀器無法快速理解。”也可能意味著“開發人員在嘗試呼叫或修改此程式碼時可能會引入錯誤。”

過度設計一種特殊的複雜性，即開發人員使程式碼變得比實際需要的通用，或者增加了系統目前不需要的功能。評審人員應特別警惕過度設計。鼓勵開發人員解決他們現在需要解決的已知問題，而不是解決開發人員推測的將來可能需要解決的問題。未來的問題應該在它們出現之後再去解決，因為到了那個時候我們可以看到它們的實際狀況和需求。

測驗

根據更改要求進行單元測試，整合測試或端到端測試。通常，除非 CL 處理緊急情況，否則應在與生產程式碼相同的 CL 中新增測試 。

確保 CL 中的測試正確，合理且有用。測試無法自我測試，我們很少為測試編寫測試，所以必須確保測試有效。

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

請記住，測試也是必須維護的程式碼。

命名

開發人員是否使用了良好的命名方式？好的命名要能夠充分表達一個項（變數、類名等）是什麼或者用來做什麼，但又不會因為太長而難以閱讀。

註釋

開發人員是否用可理解的自然語言寫下清晰的註釋？所有註釋都是必要的嗎？通常，好的註釋應該解釋為什麼存在某些程式碼，而不應該解釋某些程式碼在做什麼。如果程式碼不夠清晰，無法解釋自身，則應使簡化程式碼。也有一些例外情況（例如，正規表示式和複雜演算法通常會在註釋中解釋它們的作用，會讓閱讀程式碼的人受益匪淺），但大多數註釋是針對程式碼本身可能無法包含的資訊，比如這些程式碼背後的緣由。

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

請注意，註釋與類，模組或函式的文件不同，註釋應表示一段程式碼的用途，應如何使用以及使用時的行為。

程式碼風格

谷歌為主要程式語言和大多數次要程式語言提供了程式碼風格指南，確保 CL 遵循適當的風格指南。

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

開發人員不應將主要風格更改與其他更改結合在一起。這使得很難看到 CL 中的更改，使合併和回滾更加複雜，並導致其他問題。例如，如果開發人員想要重新格式化整個檔案，請他們僅將重新格式化的格式作為一個 CL 傳送給評審人員，然後再傳送另一個具有功能更改的 CL。

文件

如果 CL 改變了使用者構建，測試，與程式碼互動或釋放程式碼的方式，請檢查其是否還更新了相關文件，包括 README，g3doc 頁面和其他生成的參考文件。如果 CL 刪除或棄用了程式碼，請考慮是否還應刪除該文件。如果文件缺失，要向開發人員索要。

每一行程式碼

檢視每一行程式碼。有時可以掃描諸如資料檔案，生成的程式碼或大型資料結構之類的東西，但不要掃描人工編寫的類，函式或程式碼塊，並假設其中的內容是可以正常執行的。顯然，某些程式碼比其他程式碼更需要仔細檢查 —— 至於是哪些程式碼完全取決於你，但你至少應該要理解這些程式碼都在做些什麼。

如果程式碼很複雜或者你難以快速看懂它們，這會使評審速度變慢，那麼你應該讓開發人員知道這一點，並等待他們解釋，然後再嘗試評審。Google 聘請了出色的軟體工程師，如果他們看不懂程式碼，其他開發人員也很可能看不懂。因此，要求開發人員進行解釋，也可以幫助將來的開發人員理解此程式碼。

如果您理解程式碼，但又沒有資格進行程式碼評審，請確保在 CL 上有一位合格的評審人員，特別是在複雜性問題（例如安全性，併發性，可訪問性，國際化等）上。

上下文

通常，程式碼檢視工具只會顯示需要更改部分的幾行程式碼。但是有時必須檢視整個檔案，以確保更改確實有意義。例如，你可能會看到僅新增了四行程式碼，但是當你檢視整個檔案時，您會看到這四行位於 50 行方法中，這個時候需要將其分解為較小的方法。

需要基於整個系統來考量 CL 。此 CL 是在改善系統的程式碼執行狀況，還是使整個系統更加複雜，更不可測等？不要接受會降低系統程式碼執行狀況的 CL。大多數系統會通過許多小的更改而變得複雜，因此，防止新更改中出現很小的複雜性是很重要的。

好的方面

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

總結

在進行程式碼評審時，你應確保：

• 程式碼經過精心設計。
• 該功能對程式碼的使用者來說有用。
• UI 的變更合理。
• 任何並行程式設計都是安全完成的。
• 程式碼複雜性不要超過應有的程度。
• 不需要實現可能會在未來出現的需求。
• 程式碼具有適當的單元測試。
• 精心設計的測試用例。
• 開發人員對所有內容都清晰的命名。
• 清晰而有用的程式碼註釋，要解釋“為什麼”，而不是“什麼”。
• 恰如其分的程式碼文件化。
• 該程式碼符合我們的風格指南。

確保檢查的每一行程式碼，檢視上下文，確保改善程式碼執行狀況，並稱贊開發人員所做的出色工作。

檢查 CL

摘要

在知道了程式碼評審要關注哪些東西之後，如何有效地進行跨檔案程式碼評審呢？

• 更改程式碼有意義嗎？它有一個很好的描述嗎？
• 首先看一下變化中最重要的部分，整體設計得如何？
• 以適當的順序檢視其餘的 CL。

第一步：全面瞭解程式碼變更

檢視 CL 說明以及 CL 的一般功能。這種變更有意義嗎？如果這個變更是不必要的，請立即做出答覆，並說明為什麼不應該進行更改。當您拒絕這樣的更改時，最好還是向開發人員建議他們應該做些什麼。

例如，您可能會說：“看起來您為此做了一些出色的工作，謝謝！但是，實際上我們正打算移除這個系統，因此我們現在不希望對其進行任何新的修改。或許，您可以重構我們的新 BarWidget 類嗎？”

請注意，評審人員在拒絕當前的 CL 時要一併提出其他建議，而且還要表現地禮貌。這種禮貌很重要，因為作為開發人員，即使我們不同意，也要表明我們彼此尊重。

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

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

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

如果您發現 CL 的這一部分存在一些主要的設計問題，要立即回覆開發人員，即使您現在沒有時間評審 CL 的其餘部分。實際上，複查 CL 的其餘部分可能會浪費時間，因為如果設計問題足夠嚴重，那麼許多其他程式碼都會變得無關緊要。

為什麼要立即回覆開發人員有兩個主要原因：

• 開發人員通常會發出一個 CL，然後在等待稽核時立即基於該 CL 進行新工作。如果您正在評審的 CL 中存在重大設計問題，那麼他們也將不得不重新設計其以後的 CL。所以，最好趕在開發人員在有問題的設計上花費不必要的時間之前告訴他們。
• 重大的設計變更比小的變更需要更長的時間。為了在截止日期之前完成工作，並在程式碼庫中保留高質量的程式碼，開發人員需要儘快開始 CL 的所有重寫工作。

第三步：按適當順序檢查其餘的 CL

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

程式碼審查速度

為什麼程式碼審查應該很快？

在谷歌，我們對開發團隊的整體交付速度（而不是針對個體開發人員寫程式碼的速度）進行了優化。個體開發速度也很重要，但其重要性比不上整個團隊的開發速度。

當程式碼評審速度很慢時，會發生以下幾件事：

• 團隊的整體開發速度降低了。如果個體開發人員無法快速地對評審做出響應，可能是因為他們有其他事情要做。但是，如果每個 CL 都要等待一次又一次的評審，那麼團隊其餘成員的新功能和錯誤修復就會被延遲了幾天，幾周或幾個月。
• 開發人員開始抗議程式碼評審過程。如果評審人員僅每隔幾天回覆一次，但每次都要求對 CL 進行重大更改，那麼這對於開發人員來說可能是非常令人沮喪且困難的。通常，這表示為對評審人員的“嚴格”程度的抱怨。如果評審人員能夠快速提供反饋（確實可以改善程式碼執行狀況的更改），抱怨就會消失，即使他們要求做出的修改是一樣的。實際上，大多數對程式碼評審過程的抱怨都可以通過加快評審過程來解決。
• 程式碼的質量可能會受到影響。當評審速度緩慢時，開發人員的壓力也會隨之增加，因為他們不能提交不甚完美的 CL。緩慢的評審流程還會阻礙程式碼清理、重構和對現有 CL 做出進一步改進。

程式碼審查應該有多快？

如果你不是在集中精力完成手頭的任務，那就應該在第一時間評審程式碼。

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

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

速度與中斷

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

所以，對於這種情況，可以等到你手頭工作可以停了再開始程式碼評審。可以是在完成手頭的編碼任務之後，午飯後，會議結束後，休息結束後等。

快速響應

我們所說程式碼評審速度指的是響應時間，而不是 CL 通過整個評審流程並提交所花的時間。整個過程在理想情況下也應該是很快的，但單次評審請求的響應速度比整個過程的響應速度更重要。

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

如果您忙於在 CL 上進行全面評審時，仍然可以先傳送一個快速響應，以使開發人員知道什麼時候可以開始評審，或者建議讓其他可以更快做出響應的評審人員來評審程式碼，或者提供一些初步反饋。

重要的是，評審人員應花費足夠的時間進行評審，以確保此程式碼符合標準。但不管怎樣，最好響應速度還是要快一些。

跨時區程式碼評審

在處理跨時區程式碼評審時，請在他們仍在辦公室時嘗試與開發人員聯絡。如果他們已經回家了，那麼最好可以確保他們在第二天回到辦公室時可以看到程式碼評審已經完成。

LGTM 帶註釋

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

• 評審人員確信開發人員將會處理好評審人員給出的建議和意見。
• 其餘的改動是次要的，不一定要求開發人員完成。

除非另有明確說明，否則評審人員應使用這些選項中的一個。

當開發人員和評審人員處於不同時區時，帶有註釋的 LGTM 特別值得考慮，否則開發人員將等待一整天才獲得“ LGTM，批准”。

大型的 CL

如果有人向您傳送了一個很大的程式碼評審，您不確定何時可以有時間對其進行評審，通常的響應應該是要求開發人員將 CL 拆分為多個相互構建的較小的 CL。 而不必一次審查所有巨大的 CL。這樣通常是合理的，並且對評審人員很有幫助，即使需要開發人員做些額外的工作。

如果不能將一個 CL 分解為較小的 CL，並且您沒有時間快速評審整個 CL，那麼至少要對 CL 的總體設計寫一些註釋，然後將其發回給開發人員進行改進。作為評審人員，您的目標之一應該是是在不影響程式碼質量的情況下快速對開發人員做出響應，或者讓他們能夠快速採取進一步行動。

持續程式碼評審的改進

如果您遵循了這些準則，並且嚴格執行程式碼評審，則應該發現整個程式碼評審過程會隨著時間的流逝而越來越快。開發人員知道為了保證程式碼質量需要做些什麼，並從一開始就向你傳送非常棒的 CL，這樣評審所需的時間就會越來越少。評審人員學會如何快速做出響應，並且不會在評審過程中增加不必要的延遲。但是，不要在程式碼評審標準或質量上做出讓步以提高速度 —— 從長遠來看，這不會使任何事情更快地發生。

緊急情況

在某些緊急情況下，CL必須非常快速地通過 整個稽核過程，並且質量準則將得到放寬。但是，請參閱什麼是緊急情況？描述哪些情況實際上可以視為緊急情況，哪些不可以。

評審註釋

摘要

• 禮貌。
• 說明您的理由。
• 在給出明確的指示與指出問題並讓開發人員決定之間做出權衡。
• 鼓勵開發人員簡化程式碼或新增程式碼註釋，而不僅僅是讓他們解釋複雜性。

禮貌

通常，重要的是要禮貌和尊重，同時也要對要檢視其程式碼的開發人員非常瞭解。一種方法是確保您的註釋是針對程式碼，而是對開發人員。肅然不必總是遵循這種做法，但是在說出可能會令人沮喪或引起爭議的內容時，一定要使用它。例如：

不好的說法：“為什麼要在這個地方使用執行緒，這樣做顯然不會獲得任何好處”

好的說法：“併發模型在這裡增加了系統的複雜性，而我沒有看到任何實際的效能優勢。由於沒有任何效能上的好處，因此最好將此程式碼為單執行緒而不是使用多個執行緒。”

解釋理由

從上面的正確示例中可以看出，這樣有助於開發人員理解為什麼要給出這些建議。您不一定總是需要在評論註釋中包含此資訊，但是有時適當的做法可以成為對您的意圖的理解，所遵循的最佳實踐或您的建議如何改善程式碼質量進行更多說明。

提供指導

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

但是，這並不意味著評審人員不應該給予幫助。通常，您應該在指出問題和提供直接指導之間取得適當的平衡。指出問題並讓開發人員做出決定通常可以幫助開發人員學習，並使程式碼評審更容易。這也可以帶來更好的解決方案，因為開發人員比評審人員更接近程式碼。

但是，有時直接給出指令指令，建議甚至程式碼會更有幫助。程式碼評審的主要目的是獲得最佳的 CL。第二個目的是提高開發人員的技能，以便他們之後的評審會越來越少。

接受註釋

如果您要求開發人員解釋一段您不理解的程式碼，他們通常會去重寫程式碼。有時，在程式碼中新增註釋也是一種適當的響應，只要它不只是解釋過於複雜的程式碼即可。

僅在程式碼檢查工具中編寫的說明對將來的程式碼閱讀者沒有幫助。只有少數情況可以接受這種做法，例如，你對評審的東西不太熟悉，而開發人員的解釋卻是很多人所熟知的。

程式碼評審回推

有時，開發人員會回推程式碼評審。他們可能會不同意您的建議，或者會抱怨您總體上過於嚴格。

誰是對的？

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

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

如果評審人員認為他們的建議可以改善程式碼質量，並認為評審所帶來的程式碼質量改進值得開發人員做出額外的工作，那麼他們就應該堅持。改善程式碼質量往往是由一系列的小步驟組成的。

有時，在真正提出建議之前，需要花很多時間去解釋。請確保始終保持禮貌，並讓開發人員知道您瞭解他們在說什麼，您只是不同意。

煩惱的開發人員

評審人員有時認為如果他們堅持要開發人員做出改動，會使開發人員感到沮喪。有時，開發人員確實會感到不高興，但這通常是短暫的，之後他們會非常感謝您幫助他們提高了程式碼質量。如果您表現的很有禮貌，那麼開發人員根本不會感到不開心，這種擔心可能是多餘的。煩惱通常與評審人員的註釋編寫方式有關 ，而不是與評審人員對程式碼質量的堅持。

稍後解決

回退的一個常見原因是開發人員想要完成任務（可以理解）。他們不想僅僅為了獲得此 CL 而進行另一輪評審。因此，他們說他們將在以後的 CL 中清理某些內容，因此評審人員現在應該 LGTM 此 CL。一些開發人員對此非常好，並會立即編寫後續的 CL 來解決此問題。但是，經驗表明，開發人員編寫原始 CL 的時間越長，他們進行後續修復的可能性就越小。實際上，除非開發人員在提交當前的 CL 之後立刻修復，否則在通過之後通常不會再去做這件事情。這不是因為開發人員不負責任，而是因為他們有很多工作要做，所以修復工作通常會被遺忘。因此，最好是堅持要求開發人員在程式碼進入程式碼庫並“完成”之前立即修復其 CL 。讓開發人員“稍後解決”是程式碼庫退化的一種常見方法。

如果 CL 引入了新的複雜性，除非是緊急情況，否則必須在提交之前將其清除。如果 CL 暴露了一些問題，並且現在無法解決，那麼開發人員應把錯誤記錄下來，分配給自己，以免丟失。他們還可以選擇在引用已提交錯誤的程式碼中編寫 TODO 註釋。

抱怨評審過於嚴格

如果您以前對程式碼的評審不是那麼嚴格，但是卻突然變得嚴格起來，那麼一些開發人員將會大聲抱怨。不過沒關係，提高程式碼評審的速度通常會使這些抱怨消失。

有時，這些抱怨可能需要經過數月的時間才會消失，但是最後開發人員會看到嚴格的程式碼評審的價值，因為他們會看到嚴格的程式碼評審幫助自己產出優秀程式碼。有時候，如果發生這種事情，聲音最強烈的抗議者甚至會成為您最堅強的支持者。

解決衝突

如果您遵循上述所有內容，但是在程式碼評審過程中仍然遇到無法解決的衝突，請再次參閱以上內容以獲取有助於解決衝突的指導準則。

原文連結：How to do a code review