处理代码评审中的反驳

有时开发者会在代码评审中反驳你，他们可能不同意你的意见，或者抱怨你太严格了。

谁是谁非？

当开发者不同意你的建议时，首先花点思考下他们是否是对的，但通常而言你比他们更熟悉代码，所以可能在某个方面理解更深。他们的争论有意义吗？从代码健康的角度来看他们的反驳有意义吗？如果是，让他们知道他们是对的，然后这个问题就解决了。

然而，开发者不总是对的，这种情况下评审者应当进一步介绍为什么他们的建议是对的。好的解释不仅得体现出对开发人员回复的理解，而且还要说明为什么要这么改。

如果评审者认为他们的建议可以改善代码质量，并且他们认为带来的代码质量改进值得开发者做这些额外的工作，评审者就应该坚持自己的立场。 不积跬步无以至千里，不积小流无以成江河

有时候要让开发者接受，你得花很多时间反复解释，但始终确保该有的礼貌，并让开发者知道你听到了他们在说什么，即便是你不同意。

惹恼开发者

有时评审者会认为坚持让开发者做出改动，可能会惹恼开发者。有时开发者确实会恼怒，但这种情况通常都很短暂，而且之后他们会感激你帮助他们提高了代码质量。 如果你在代码评审中很有礼貌，开发者根本不会被惹恼，这种担心是多余的。通常，令惹恼开发者的是你写注解的方式，而不是你对代码质量的坚持。

稍后解决

一种常见的反驳原因是开发者希望能尽快完成任务。他们不想一轮又一轮地做代码评审，然后就会说他们会在后续CL中处理这些问题，你只需要通过就行。有些开发者做的很好，他们会立马提交后续CL处理这些问题。然而，经验告诉我们原始CL通过之后拖的时间越久，就越不可能修复。除非开发者在当前CL通过后立马修复，否则他们就不可能修复。这并不是开发者不负责任，而是因为他们有好多工作要做，而修复工作也会因为工作压力而被遗忘。所以最好坚持让开发者现在就在CL中处理掉这些问题，“留着以后清理”是一种不可取的方式。

如果CL中引入了新的复杂性，提交之前必须清理掉，除非是紧急情况。 如果CL中暴露出一些目前还无法定位的问题，开发者应该记录下这些bug，并将其分配给他们自己，确保这些问题不会被遗忘。他们还可以在代码中加入 TODO 注释，指向已经记录好的 bug。

抱怨太严格

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

有时，这些抱怨可能需要几个月的时间才能消除，但最终开发者在看到产出的优质代码时会理解严格代码评审带来的价值。有时候，一旦发生某些事让他们真正看到严格代码评审的价值，抗议最大声的人甚至会成为你最坚定的支持者。

解决冲突

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