原文
https://google.github.io/eng-practices/review/reviewer/pushback.html
Handling Pushback in Code Reviews (如何面对被推迟处理的评论)
有时开发人员会推迟处理程式审查产生的评论。要么他们不同意你的建议,要么他们会抱怨你太严格了。
Who is right? (谁是对的)
当开发人员不同意你的建议时,请先花点时间考虑一下他们是否是正确的。因为通常他们比你更接近程式码,所以他们可能真的比起你来说对程式的某些层面具有更好的洞察力。他们的论点有意义吗? 从程式品质的角度来看它是否合理? 如果是的话,让他们知道他们是对的,然后让问题沉下去。
但开发人员也并不总是对的。在这种情况下,审核者应该更进一步解释为什么认为自己的建议是正确的。一个好的解释通常展示了「对开发人员的回覆的理解」以及有关「为什么被要求对出做出改动」等资讯。
尤其是当审核人员认为给出的建议会改善程式品质时,便应该继续宣扬自己的论点。只要他们相信所需的额外的工作量最终会改善整体程式品质。
提高整体程式健康状况这件事,往往是经由每个微小的改动来发生
有时往往需要几番解释一个建议才能让对方真正理解你的用意。切记,始终保持礼貌,让开发人员知道你有听到他们在说什么,只是你不同意该论点而已。
Upsetting Developers (让开发者沮丧)
审核者有时会认为若自己坚持改进的话,会让开发人员觉得沮丧不安。的确开发人员有时会感到很沮丧,但这通常是十分短暂的,甚至后来他们非常感谢你帮助他们提高程式品质。一般来说,只要你在评论中表现得很有礼貌,开发人员实际上根本不会感到沮丧,这些担忧都仅存在于审核者心中而已。沮丧很多时候是对于审核评论的写作方式有关,而并非来自审核者对于程式品质的坚持。
Cleaning It Up Later (晚点再来整理干净)
一个常见的推迟原因是开发人员希望完成任务(这可以理解)。他们不想通过另一轮审查来批准这个CL。此时他们通常会说在以后的CL进行整理,所以你现在应该要给LGTM。当然部分开发人员非常擅长这一点,并且立即送出一个修复问题的后续CL (follow-up CL),但根据过往经验,这种后续「清理行为」非常少见。除非开发者在CL获得批准之后立刻进行清理动作,否则这事根本不可能发生。这不是因为开发人员不负责任,而是因为他们可能有很多其他工作要完成,于是清理工作便会在成堆的工作中被遗忘。因此,通常最好坚持开发人员在程式在合併進程式庫之前清理他們的 CL,因为让人们「稍后清理」是致使程式库健康状况下降最常见的状况。
如果CL引入了新的复杂性的话,除非是紧急情况,否则必须在提交之前将其处理掉。如果CL导致暴露周围的问题(surrounding problems)且现在无法解决它们的话,开发人员应该将缺陷记录下来并分配给自己,避免后续被遗忘。又或者他们可以选择在程式中留下TODO的注释并连结到刚记录下的缺陷。
General Complaints About Strictness (关于审核严格性的常见抱怨)
如果你先前以相当宽松的标准并转趋严格的进行程式审查的话,一些开发人员会开始大声地抱怨。一般来说,提高审查的速度会让这些抱怨逐渐消失。这些抱怨可能需要数个月才会消失,但最终开发人员会看到严格的审查所带来的价值,因为严格的审查帮助他们产生的优秀程式码。而且一旦发生某些事情时,最大声的抗议者甚至可能会成为你最坚定的支持者,因为他们会看到变得审核变严格后所带来的价值。
Resolving Conflicts (解决冲突)
如果你遵循前面所有操作,但仍然遇到无法解决的双方之间的冲突时,请参阅The Standard of Code Review以获取有助于解决冲突的准则和原则。