Google代码健康：尊重的评审==有用的评审

本文源于Google公司的马桶上的健康代码，作者：Liz Kammer (Google)、Maggie Hodges (UX research consultant)&Ambar Murillo (Google)

尽管代码审查被认为是提高软件项目质量的有价值的工具，但是不明确或苛刻的代码评审评论可能会带来不利的后果：缓慢的评审，受阻的依赖代码评审，负面情绪或对其他贡献者或同事的负面看法。

考虑下面的小技巧来实现尊重地开展代码评审评论。

作为评审者或作者：

做：假设能力。 作者的实现或评审者的意见可能是由于另一方与你的情况不同。首先提出问题以获取理解。

做：提供理论或上下文，例如最佳实践文档，样式指南或设计文档。这可以帮助其他人了解您的决定或提供指导。

做：考虑如何解释评论。 请注意夸张，笑话和表情符号可能会被察觉的不同方式。

作者不应：
我更喜欢短名称，所以我不想更改它。 除非你要求我？ :)

作者应该：
最佳实践建议省略明显/通用的术语。 我不确定如何将该建议与该情况相结合。

不做：批评人。 而是，讨论代码。甚至认为评论是针对某人的（例如，由于使用“你”或“你的”而引起的）都偏离了改进代码的目标。

评审者不应：
为什么使用这种方法？你在添加不必要的复杂性。

评审者应该：
这种并发模型似乎给系统增加了复杂性，而没有任何明显的性能优势。

**不做：使用苛刻的语言。 **带有负面语气的代码评审意见不太可能有用。例如，之前有研究发现，非常负面的评审意见被作者认为有用率为57％，而比较中立的评论则为79％。

作为评审者：

做：提供具体可行的反馈。 如果没有具体的建议，有时可以要求你对作者澄清做出决定的原因。

评审者不应：
我不理解这些内容。

评审者应该：
如果这是一种优化，可以添加注释吗？

做：清楚地标记出nitpicks和可选意见（使用“ Nit”或“ Optional”之类的前缀）。这使作者可以更好地理解评审人的期望。

作为作者：

做：澄清代码或回复评审者的评论以响应反馈。否则，可能表明缺乏接受对代码进行改进的意愿。

作者不应：
在某些情况下，这是有道理的，但在这里没有。

作者应该：
我添加了关于为什么要以这种方式实现的评论。

做：在不同意反馈时，请说明你的方法的优势。 如果无法达成共识，请按照Google的指南解决代码评审中的冲突。

尊重的评审==有用的评审