代码评审回推

有时候，开发人员会回推代码评审。他们可能不同意你的意见，或者他们抱怨你太严格了。

谁是对的？

如果开发人员不同意你的意见，先花点时间想一下他们是不是对的。通常，他们比你更熟悉代码，所以可能对代码的某些方面更了解。他们的论点有道理吗？从代码质量角度来看，他们的回推是有道理的吗？如果是，就让他们知道他们是对的，这个问题就解决了。

然而，开发人员并不总是正确的。在这种情况下，评审人员要进一步解释为什么他们的建议是正确的。

如果评审人员认为他们的建议可以改善代码质量，并认为评审所带来的代码质量改进值得开发人员做出额外的工作，那么他们就应该坚持。改善代码质量往往是由一系列的小步骤组成的。

有时候你需要花很多时间反复解释，但要始终保持礼貌，并让开发人员知道你知道他们在说什么。

激动的开发人员

有时候，评审人员会认为如果他们坚持要开发人员做出改动，会让开发人员感到不安。开发人员有时候确实会感到沮丧，但这种感觉通常都很短暂，之后他们会非常感谢你帮助他们提高了代码质量。如果你在评审过程中表现得很有礼貌，开发人员一点都不会感到不安，这种担心可能是多余的。通常，令开发人员感到不安的是你写注解的方式，而不是你对代码质量的坚持。

稍后再解决

一种常见的回推原因是开发人员希望尽快完成任务。他们不想经过一轮又一轮的代码评审，他们说他们会在后续的CL中解决遗留问题，你现在让CL通过就可以了。一些开发人员会做得很好，他们在提交CL后立即就开发后续的CL。但经验表明，开发人员开发原始CL的时间越长，他们进行后续修复的可能性就越小。除非开发人员在提交CL之后立即进行修复，否则在通过之后通常不会再去做这件事情。这并不是因为开发人员不负责任，而是因为他们有很多工作要做，而修复工作通常会被遗忘。所以，最好让开发人员马上把CL修复掉。

如果CL引入了新的复杂性，在提交之前必须将其清理掉，除非是紧急情况。如果CL暴露了一些目前还无法解决的问题，开发人员需要把bug记录下来，并将其分配给自己，这样它就不会被遗漏。他们还可以在代码中加入TODO注释，指向已经记录好的bug。

抱怨评审太严格

如果你之前的代码评审很放松，然后突然变得严格起来，可能会引起一些开发人员的抱怨。不过没关系，加快代码评审速度通常会让这些抱怨逐渐消失。

有时候，这些抱怨可能需要几个月的时间才能消除，但开发人员到最后通常会看到代码评审的价值，因为他们看到了严格的代码评审有助于产出优秀的代码。有时候，抗议最大声的人甚至会成为你最坚定的支持者。

解决冲突

如果你遵循了上述方法，但仍然会在评审过程中遇到无法解决的冲突，请再次参阅代码评审标准，了解那些有助于解决冲突的指导原则。