文 / Liz Kammer (Google)、Maggie Hodges（用户体验研究顾问）和 Ambar Murillo (Google)
这是我们 代码健康 系列的另一篇文章。这篇文章最早出现在世界各地的 Google 卫生间中，是 Google 盥洗室测试法 (Testing on the Toilet) 的一部分。您可以下载打印专用版，以便在办公区内展示。
虽然代码审查被视作提高软件项目质量的重要工具，但模糊不清或严苛的代码审查评论可能会带来不利后果：导致审查进度缓慢、阻碍相关代码审查，其他代码贡献者或同事的负面情绪甚至负面看法。
请参考以下技巧，让代码审查评论更易被接受。
作为代码审查者或作者：
应该：换位思考。无论是作为代码作者还是审查者，由于身份/背景不同，您的代码部署或审查建议往往会与对方的理解有歧义。多提问题，便于彼此理解。
应该：提供基本原理或上下文，例如最佳实践文档、风格指南或设计文档。这有助于其他人理解您的做法，或者为您提供指导。
应该：考虑他人会如何解读评论。注意，夸张语句、笑话以及表情符号可能会造成误解。
代码作者不应该：
我喜欢用缩写，所以我不会修改的（你咬我啊）。
代码作者应该：
最佳实践建议使用某些术语的缩写，我不太确定应该如何遵守这个规范，有什么好的建议吗？
不应该：指责别人。应该仅针对 代码 进行讨论。认为评论掺杂个人感情（比如使用了“你”或“你的”）会干扰您改良代码。
审查者不应该：
你为什么要用这种方法？你这样增加了不必要的复杂性。
审查者应该：
这种并发模型好像增加了系统复杂性，并且没有任何可见的性能改善。
不应该：使用严苛的表述。带有负面语气的评论并没有多大帮助。例如，据调查显示，对于代码作者而言，仅在 57% 的情况下他们会考虑或接受非常负面的评论，而在 79% 的情况下他们都会考虑或接受中立的评论。
作为代码审查者：
应该：提供具体且可执行的反馈。如果没有具体的建议，可以让作者阐述这样做的原因，这种做法有时会很有帮助。
审查者不应该：
我不懂这个（）
审查者应该：
如果这是一个优化方法的话，
你能加一些关于这个方法的介绍吗？
应该：清晰地标明必须注意和选择性注意的评论，可以用诸如“Nit”或“Optional”等前缀。这样可以让代码作者更好地了解审查者的期望。
作为代码作者：
应该：阐述代码或回复审查者的评论，以示对评论的回应。否则，审查者可能会认为您不愿意对代码实施改进。
代码作者不应该：
某些情况下是有用的，不过不是这里（）
代码作者应该：
我加了一些内容，解释了这样做的必要性。
应该：在不认同反馈时说明您所用方法的优势。如果双方无法达成共识，可以遵循 Google 关于如何在代码审查中解决意见冲突的指导。
如果您想详细了解 本文讨论 的相关内容，请参阅以下文档。这些文档深入探讨了这篇文章中提及的许多主题：
代码健康
https://testing.googleblog.com/2017/04/code-health-googles-internal-code.htmlGoogle 盥洗室测试法
https://testing.googleblog.com/2007/01/introducing-testing-on-toilet.html下载打印专用版
https://docs.google.com/document/d/1_Gljf1TMTV2WPsiXCdk8oIkiq6uiajN_IqGdlD7u3Mc/edit?usp=sharing重要工具
https://dl.acm.org/citation.cfm?id=3183525解决意见冲突
https://google.github.io/eng-practices/review/reviewer/standard.html#conflicts
