google code review系列6 - 处理code review中的pushback(完结篇)-CSDN博客

接上篇：google code review系列5 - 如何编写code review评论。本篇是code review的完结篇，pushback可以解释成对code review出来的问题的拖延、推拒和抵制。本篇主要讲述reviewer和开发人员存在建议冲突时如何处理，面对开发人员承若延后处理应该如何操作，以及面对code review过程中的抱怨应该如何应对，让codereview的抵抗者变成最坚强的支持者

翻译：

https://google.github.io/eng-practices/review/reviewer/standard.html

Code Review名词解释

整个Code Review分成如下五个部分，本节主要讲述Google在code review中寻找什么？

code review的标准
在code review中寻找什么
浏览审查中的CL
code review的速度
如何编写code review评论
处理code review中的pushback

有时开发人员会抵制code review。要么他们不同意你给的建议，要么他们会抱怨你code review太过严格了。

谁是对的呢？

当开发人员不同意你给的建议时，首先我们要考虑一下他们原先的方案是否正确。通常，开发人员比你更接近代码和了解需求，因此他们对代码的某些方面比你更了解。他们的论点有意义吗？从代码健康角度来看，这有意义吗？如果是这样，请让他们知道他们是对的，然后解决问题。(code review 的精髓不在于告诉开发人员：你不行，这是非常错误的思想。)

然而，开发人员并不总是正确的。在这种情况下，reviewer应该进一步解释为什么他们认为他们的建议是正确的。一个好的解释不仅说明了对开发人员的回答的理解，也说明了为什么开发人员需要做出更改的其他信息。

特别是，当reviewer认为他们的建议将改善代码的健康状况时，如果他们认为所产生的代码质量改进能够证明所要求的额外工作是合理的，那么他们应该继续提倡更改。改善代码健康状况往往是一些小步骤。

有时候，为了让开发人员真正理解你的一个建议之前，您需要花几轮时间来解释它。你只要确保始终保持礼貌，并让开发人员知道你听到了他们在说什么，你只是不同意他们的观点而已。

沮丧的开发者

reviewer有时认为，如果reviewer坚持改进，开发人员会感到不安。有时候开发人员会感到很沮丧，但这样的感觉通常只会持续很短的时间，后来他们会非常感谢您在提高代码质量方面给他们的帮助。通常情况下，如果您在评论中表现得很有礼貌，开发人员实际上根本不会感到沮丧，这些担忧都仅存在于reviewer心中而已。开发者感到沮丧通常更多地与评论的写作方式有关，而不是reviewer对代码质量的坚持。（对事不对人的态度很重要。）

稍后处理

开发人员拖延的一个常见原因是开发人员（可以理解）希望完成任务。他们不想通过另一轮审查来完成该 CL。所以他们说会在以后的 CL 中处理一些东西，所以你现在应该 LGTM 这个 CL。一些开发人员非常擅长这一点，并会立即编写一个修复问题的后续 CL。但是，经验表明，在开发人员编写原始 CL 后，经过越长的时间这种处理发生的可能性就越小。实际上，通常除非开发人员在当前 CL 之后立即进行处理，否则它就永远不会发生。这不是因为开发人员不负责任，而是因为他们有很多工作要做，处理工作在其他工作中被丢失或遗忘。因此，在代码进入代码库并“完成”之前，通常最好坚持让开发人员现在处理他们的 CL。让人们“稍后处理东西”是代码库质量退化的常见原因。

如果 CL 引入了新的复杂性，除非是紧急情况，否则必须在提交之前将其清除。如果 CL 暴露了相关的问题并且现在无法解决，那么开发人员应该将 bug 记录下来并分配给自己，避免后续被遗忘。又或者他们可以选择在程序中留下 TODO 的注释并链接到刚记录下的 bug。

总的来说，口头的“以后再改”是不靠谱的，通常情况下是不会去改的，除非特别紧急的情况下，我们都应该在merge代码库之前修复code review发现的问题，或者通过bug记录和TODO注释去记录这些问题。

关于严格性的抱怨

如果您以前的代码审查相当松散，而现在改为进行严格的审查，一些开发人员会大声抱怨。提高代码审查的速度通常会导致这些投诉逐渐消失。

有时，这些抱怨可能需要几个月的时间才能消失，但最终，开发人员在看到自己帮助生成了多么优秀的代码时，往往会看到严格的代码审查的价值。有时，一旦发生了一些事情，让他们真正看到你通过严格要求所增加的价值，最大声的抗议者甚至会成为你最坚定的支持者。

对严格的普遍抱怨

如果你以前的code review很松散，而现在code review变得非常严格，那么一些开发人员将会非常大地抱怨。提高code review的速度通常会使这些抱怨逐渐消失。

有时，这些抱怨可能会持续数月的时间才能消失，但是最终，开发人员往往会看到严格的code review的价值，因为他们会看到自己的代码越写越出色。往往会看到严格的code review的价值，有时，一旦发生某种事情，让它们真正看到你通过严格要求后，所增加的价值，最强烈的抗议者甚至会成为你最坚强的支持者。

解决冲突

如果您遵循上述所有方法，但仍然遇到自己和开发人员之间无法解决的冲突，请参考前面的5篇文章，它们了解有助于解决冲突的指导原则和原则。

往期阅读

google code review系列5 - 如何编写code review评论

google code review系列4 - code review的速度

google code review系列3 - 浏览审查中的change list

google code review系列2 - 在code review中寻找什么?

google code review系列1 - code review的标准