google code review 06

原文
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以获取有助于解决冲突的准则和原则。