处理代码审核中的拒绝反馈
有时候开发者会在代码审核后给出拒绝或者负面的反馈。或者是不同意你的建议，或者是抱怨在整体过于严格。
谁对谁错？
当开发者不同意你的建议时，先确认一下他们是不是正确的。通常他们更加靠近代码，所以对于代码的具体方面可能他们会有更好的了解。他们的意见是否合理？从代码质量的角度考虑是否合理？如果是合理的，告诉他们是正确的，并且关闭这个问题。
然而开发者并非都是正确的，这时审核者需要进一步解释为什么认为提供的审核建议是正确的。好的解释不单单表示了对于开发者回复的理解,还附加了审核要求的理由.
特别当审核者确信他们的建议能够提升代码质量，如果他们认为代码质量的改进值得投入额外的工作量的话，他们就会持续的主张进行变更。代码质量提升是通过不断小步改进达成的。
有时最终结论敲定之前会需要经过多轮讨论。记得在过程中一定要保持礼貌，并且让开发者知道你听到理解了他们的回复，而不单单只是附和性的赞同。
沮丧的开发者
审核者有时会认为自己坚持某一个改进会导致开发者感觉沮丧。有时开发者会有负面情绪，但是这是短暂的而且他们最终还是会感谢你帮助他们提高了代码质量。通常只要你在评论中保持礼貌，开发者根本不会有负面的情绪，他们只会担心审核者的想法。沮丧通常是因为评论的写法，而不是审核者坚持改进代码质量。
延迟修复
常见的开发者拒绝的原因是希望能够将事情完成，他们希望不要再经过另一轮的审核才能够提交完变更。因此他们会承诺会在稍后的提交中修复一些问题，所以你会对当前标记通过。有些开发者是十分守信的，他们会立即开始下一个提交来修复这些问题。但是经验表明，当原始提交之后时间间隔越长，开发者提交修复的可能性越低。实际上除非开发者在当前提交后立即修复问题，否则就不可能再修复了。不是因为开发者没有责任感，是因为他们手头还有大量的工作要处理，所以在其他工作的压力之下遗失或者忘记了修复的工作。因此最好的做法就是坚持开发者要在当前提交中修复，避免代码进入代码基线后成为“完成事实”。允许大家“延迟修复”就是代码质量恶化的常见原因。
如果提交引入了新的复杂度，在提交前必须要修复，除非存在紧急情况。如果提交中存在环境问题可能无法现在就定位，开发者应当针对修复建立一个文件或任务，防止最终被遗忘。也可以再代码中写一个待办注释关联到这个Bug上。
关于严格性的常见抱怨
如果你之前是比较宽松的代码审核的风格，接下来切换到比较严格的要求时，开发者会更大声地抱怨。只要你持续提高审核的速度这些抱怨慢慢就会淡化。
有时这个过程长达数月，但是最终开发者会意识到审核的价值，当他们看到这些行为协助产生了优秀的代码。有时抱怨的最大声的人最终会成为你最坚定的支持者，只要有一次他们发现你的严格审核带来的价值就好。
处理冲突
如果你遵从上面提到的建议，你会发现审核者和开发者之间的任何问题都是可以解决的，根据代码审核标准作为行为指南和准则会帮助你解决冲突。
我的总结
至此，谷歌在Github上分享的最佳实践 - 关于代码审核的准则部分都已经完结了。我整体的理解，其实谷歌还是使用很简洁直白的行为准则，但是也给出了一些宽容，毕竟软件开发中还是存在弹性的空间的。但是大企业的人员编制和素质实际上是谷歌这份文档中没有提到的很重要的因素之一。如果一个企业，存在工期、人力资源、成本等等压力之下，要给出编制和工时来坚持进行代码审核，实际上无论使用什么准则，我觉得都能够存在比较好的质量管控。之后再来参考谷歌的这份最佳实践，结合自己的实际情况来修正自己企业的流程或者规范。
除了大部分代码格式规范、编码规范能够直接拿来使用，针对人员，组织，流程等的规范和建议都应该是参考，结合自己的实际情况和当前存在最尖锐的问题，来进行幅度较小的调整。
所以，最后还是感触最深的那句话：一些管理手段都是为了解决问题，而不是彰显权力或者制造问题。所以当大家想要引入某种流程、制度、规范，要充分收集大家的意见，现在组织当中是否存在问题，引入之后是不是能解决问题。只要能解决问题，在组织中推动就不会存在大的障碍，因为提升了大部分人的效率。