處理代碼審覈中的拒絕反饋
有時候開發者會在代碼審覈後給出拒絕或者負面的反饋。或者是不同意你的建議，或者是抱怨在整體過於嚴格。
誰對誰錯？
當開發者不同意你的建議時，先確認一下他們是不是正確的。通常他們更加靠近代碼，所以對於代碼的具體方面可能他們會有更好的瞭解。他們的意見是否合理？從代碼質量的角度考慮是否合理？如果是合理的，告訴他們是正確的，並且關閉這個問題。
然而開發者並非都是正確的，這時審覈者需要進一步解釋爲什麼認爲提供的審覈建議是正確的。好的解釋不單單表示了對於開發者回覆的理解,還附加了審覈要求的理由.
特別當審覈者確信他們的建議能夠提升代碼質量，如果他們認爲代碼質量的改進值得投入額外的工作量的話，他們就會持續的主張進行變更。代碼質量提升是通過不斷小步改進達成的。
有時最終結論敲定之前會需要經過多輪討論。記得在過程中一定要保持禮貌，並且讓開發者知道你聽到理解了他們的回覆，而不單單只是附和性的贊同。
沮喪的開發者
審覈者有時會認爲自己堅持某一個改進會導致開發者感覺沮喪。有時開發者會有負面情緒，但是這是短暫的而且他們最終還是會感謝你幫助他們提高了代碼質量。通常只要你在評論中保持禮貌，開發者根本不會有負面的情緒，他們只會擔心審覈者的想法。沮喪通常是因爲評論的寫法，而不是審覈者堅持改進代碼質量。
延遲修復
常見的開發者拒絕的原因是希望能夠將事情完成，他們希望不要再經過另一輪的審覈才能夠提交完變更。因此他們會承諾會在稍後的提交中修復一些問題，所以你會對當前標記通過。有些開發者是十分守信的，他們會立即開始下一個提交來修復這些問題。但是經驗表明，當原始提交之後時間間隔越長，開發者提交修復的可能性越低。實際上除非開發者在當前提交後立即修復問題，否則就不可能再修復了。不是因爲開發者沒有責任感，是因爲他們手頭還有大量的工作要處理，所以在其他工作的壓力之下遺失或者忘記了修復的工作。因此最好的做法就是堅持開發者要在當前提交中修復，避免代碼進入代碼基線後成爲“完成事實”。允許大家“延遲修復”就是代碼質量惡化的常見原因。
如果提交引入了新的複雜度，在提交前必須要修復，除非存在緊急情況。如果提交中存在環境問題可能無法現在就定位，開發者應當針對修復建立一個文件或任務，防止最終被遺忘。也可以再代碼中寫一個待辦註釋關聯到這個Bug上。
關於嚴格性的常見抱怨
如果你之前是比較寬鬆的代碼審覈的風格，接下來切換到比較嚴格的要求時，開發者會更大聲地抱怨。只要你持續提高審覈的速度這些抱怨慢慢就會淡化。
有時這個過程長達數月，但是最終開發者會意識到審覈的價值，當他們看到這些行爲協助產生了優秀的代碼。有時抱怨的最大聲的人最終會成爲你最堅定的支持者，只要有一次他們發現你的嚴格審覈帶來的價值就好。
處理衝突
如果你遵從上面提到的建議，你會發現審覈者和開發者之間的任何問題都是可以解決的，根據代碼審覈標準作爲行爲指南和準則會幫助你解決衝突。
我的總結
至此，谷歌在Github上分享的最佳實踐 - 關於代碼審覈的準則部分都已經完結了。我整體的理解，其實谷歌還是使用很簡潔直白的行爲準則，但是也給出了一些寬容，畢竟軟件開發中還是存在彈性的空間的。但是大企業的人員編制和素質實際上是谷歌這份文檔中沒有提到的很重要的因素之一。如果一個企業，存在工期、人力資源、成本等等壓力之下，要給出編制和工時來堅持進行代碼審覈，實際上無論使用什麼準則，我覺得都能夠存在比較好的質量管控。之後再來參考谷歌的這份最佳實踐，結合自己的實際情況來修正自己企業的流程或者規範。
除了大部分代碼格式規範、編碼規範能夠直接拿來使用，針對人員，組織，流程等的規範和建議都應該是參考，結合自己的實際情況和當前存在最尖銳的問題，來進行幅度較小的調整。
所以，最後還是感觸最深的那句話：**一些管理手段都是爲了解決問題，而不是彰顯權力或者製造問題。**所以當大家想要引入某種流程、制度、規範，要充分收集大家的意見，現在組織當中是否存在問題，引入之後是不是能解決問題。只要能解決問題，在組織中推動就不會存在大的障礙，因爲提升了大部分人的效率。