處理代碼審查中的推回
有時，開發人員會推遲進行代碼審查。他們要麼會不同意您的建議，要麼會抱怨您總體上過於嚴格。
誰是對的？
當開發人員不同意您的建議時，請先花點時間考慮一下它們是否正確。通常，它們比您更接近代碼，因此他們實際上可能對代碼的某些方面有更好的瞭解。他們的論點有意義嗎？從代碼健康角度來看，這有意義嗎？如果是這樣，請讓他們知道他們是對的，然後讓問題解決。
但是，開發人員並不總是正確的。在這種情況下，審稿人應進一步解釋爲什麼他們認爲自己的建議正確。良好的解釋不僅說明了對開發人員回覆的理解，而且還說明了爲什麼要求進行更改的其他信息。
尤其是，當審閱者認爲他們的建議將改善代碼的健康狀況時，如果他們認爲所導致的代碼質量的改善證明所要求的額外工作是合理的，則他們應繼續倡導該更改。 改善代碼運行狀況的步驟往往很短。
有時，在真正採納建議之前，需要花幾輪的時間來解釋建議。請確保始終保持禮貌，並讓開發人員知道您聽到他們在說什麼，您只是不同意。
煩人的開發人員
審稿人有時認爲，如果審稿人堅持要改進，開發人員會感到沮喪。有時，開發人員確實會感到不高興，但這通常是簡短的，後來他們非常感謝您幫助他們提高了代碼質量。通常，如果您對您的評論有禮貌，那麼開發人員實際上根本不會感到煩惱，而擔心只是在審閱者的腦海中。煩惱通常與註釋的編寫方式有關 ，而不是與審閱者對代碼質量的堅持有關。
稍後清理
回退的一個常見原因是開發人員（可以理解）想要完成任務。他們不想僅僅爲了獲得此CL而進行另一輪審覈。因此，他們說他們將在以後的CL中清理某些內容，因此您現在應該LGTM 此 CL。一些開發人員對此非常擅長，並會立即編寫後續的CL來解決此問題。但是，經驗表明，開發人員在編寫原始CL之後花費的時間越多，清理工作的可能性就越小。實際上，通常除非開發人員立即進行清理在當前的CL之後，它永遠不會發生。這不是因爲開發人員不負責任，而是因爲他們有很多工作要做，並且清理工作在其他工作中被遺忘或遺忘。因此，通常最好是堅持要求開發人員現在在代碼進入代碼庫並“完成”之前清理其CL 。讓人們“稍後清理”是代碼庫退化的一種常見方法。
如果CL引入了新的複雜性，除非是緊急情況，否則必須在提交之前將其清除。如果CL暴露了周圍的問題，並且現在無法解決，則開發人員應提交清理錯誤，並將其分配給自己，以免丟失。他們還可以選擇在引用已提交錯誤的代碼中編寫TODO註釋。
有關嚴格性的一般投訴
如果您以前對代碼的審查鬆懈，而轉而對代碼進行嚴格的審查，那麼一些開發人員將大聲抱怨。提高代碼審查的 速度通常會使這些抱怨消失。
有時，這些抱怨可能要花費數月的時間才能消失，但是最終，開發人員往往會看到嚴格的代碼審查的價值，因爲他們會看到自己幫助生成的出色代碼。有時，一旦發生某種事情，使嚴格的抗議者甚至成爲您最堅強的支持者，這會使他們通過嚴格遵守而真正看到您所增加的價值。
解決衝突
如果您遵循上述所有內容，但是仍然遇到無法解決的開發人員與您之間的衝突，請參閱 《標準代碼審查》以獲取有助於解決衝突的準則和原則。
參考
https://google.github.io/eng-practices/review/reviewer/pushback.html