有时开发人员会推回代码审查。要么他们不同意你的建议，要么他们会抱怨你太严格了。
谁是对的
当一个开发人员不同意你的建议时，首先花点时间考虑一下他们是否正确。通常，他们比你更接近代码，因此他们可能对代码的某些方面有更好的了解。他们的论点有意义吗?从代码健康的角度来看，这样做有意义吗?如果是这样，让他们知道他们是对的，让这个问题消失。
然而，开发人员并不总是正确的。在这种情况下，评审人应该进一步解释为什么认为自己的建议是正确的。一个好的解释既表明了对开发人员的回复的理解，也说明了为什么要求更改变更。
特别是，当评审人认为他们的建议将改善代码的健康状况时，如果他们认为所得到的代码质量改进能够证明所要求的额外工作是合理的，那么他们应该继续提倡更改。改善代码的健康状况往往是在小步进行的。
有时候，在真正理解一个建议之前，需要花几轮时间来解释它。只要确保始终保持礼貌，让开发人员知道你听到了他们说的话，你只是不同意。
心烦不安的开发人员
评审员有时认为，如果评审员坚持要进行改进，开发人员会感到烦躁。
有时开发人员确实会感到沮丧，但通常是简短的，之后他们会非常感谢您帮助他们提高了代码的质量。通常情况下，如果你在评论中表现得很有礼貌，开发人员实际上一点也不会感到不安，而这种担心只存在于评论者的脑海中。令人烦恼的通常是写注释的方式，而不是评审人对代码质量的坚持。
稍后再清理
推回的一个常见情况是开发人员(可以理解)希望尽快完成工作。他们不想对这个CL来另一轮的审查。所以他们说他们会在以后的CL中清理一些东西，所以你现在应该以“LGTM”来通过这个CL的代码审查。一些开发人员对此非常擅长，他们将立即编写一个后续CL来修复这个问题。然而，经验表明，在开发人员编写原始CL之后，时间越长，清理的可能性就越小。事实上，通常情况下，除非开发人员在当前CL之后立即进行清理，否则就不会清理了。这并不是因为开发人员不负责任，而是因为他们有很多工作要做，清理工作在其他工作的压力下丢失或遗忘了。因此，通常最好是坚持在代码进入代码库并“完成”之前，让开发人员现在清理他们的CL，。让人们消退这种“以后再清理”代码库的常见方式。
如果CL引入了新的复杂性，在提交之前必须进行清理，除非是紧急情况。如果CL暴露了周围的问题，而这些问题现在还不能解决，那么开发人员应该为清理工作提交一个bug，并将其分配给自己，这样它就不会丢失。他们还可以编写TODO注释关联到这个bug上。
对严格的一般性抱怨
如果你以前有相当宽松的代码审查，而你现在有严格的审查，一些开发人员将会非常大声地抱怨。提高代码评审的速度通常会使这些抱怨逐渐消失。
有时可能需要几个月的时间这些抱怨才会消失，但最终开发人员往往会看到严格的代码审查的价值，因为他们会看到Review后帮助生成的代码有多棒。有时，最大声的抗议者甚至会成为你最坚定的支持者，一旦发生了什么事情，让他们真正看到你通过严格来增加的价值。
解决冲突
如果你遵循了以上所有的原则，但是仍然遇到自己和开发人员之间的冲突，并且无法解决，那么请参阅代码审查标准，以获得有助于解决冲突的指导原则。
