InfoQ6 个实用的 Code Review 实践技巧( 三 )

以下是一些你可以遵循的技巧：
评审人可以这样想：“这是我们自己的代码，我们该如何改进它呢？”
提出肯定意见！如果你看到有些代码部分写得不错，就加条评论表扬一下。这能让代码作者继续保持好的一面，并有助于他在心理上更容易接受改进建议。
代码作者不妨这么想，评审人的出发点肯定是好的，不要将评论当作是对个人的批评。
下表列出了一些存在不足的评审反馈，以及如何按以上建议进行重写的建议。

本文插图
归根结底， code review 给我们提供了互教互学的机会，我们应该对此持开放欢迎的态度。
挑选合适的评审人决定由谁来评审你的工作通常很有挑战性。以下问题可作为参考：

谁具备你正在构建的特性或组件的上下文？
谁精通你正在使用的语言、框架或工具？
谁对这一主题知之甚深，有自己的理解？
谁关心你所写代码的结果？
谁应该学习这些东西？或者，如果你是一名正在评审“老鸟的菜鸟程序员” ，不妨抓住这个机会多多提问学习。别怕你的问题太幼稚，一个强大的团队会找时间来分享知识。

无论你的团队遵循哪些原则，请记住，作为一名代码的作者，你有责任寻求并接受适当的人对你的代码进行高质量的 code review 。
给评审人提供关键的上下文最后但同样非常重要的一点是，你的 PR 描述至关重要。这取决于你选择的评审人，不同的人会有不同的上下文。代码的作者有责任提供关键信息或更多上下文的链接，帮助评审人能够反馈有价值的意见。
你可以把以下问题放到你的 PR 模板中：

为什么这个 PR 是必要的？
谁会从中受益？
可能会出什么问题？
你还考虑过其他方法吗？你为什么决定采用这种方法？
这对其他系统有什么影响?

好的代码不仅没有错误，还非常有用。作为一名代码的作者，请确保你的 PR 描述将代码与团队目标联系起来，最好能与待办事项中的特性或缺陷描述联系起来。作为评审人，会先评审 PR 描述，如果它不够完整，你是无法针对未定义的目标来判断代码是否适当的，不如在评审代码前就把它打回去。请记住，有时代码审查的最佳结果是认识到根本不需要这些代码！
我们会有哪些收获?通过采用上面的一些技术，你可以在很大程度上影响软件构建过程的速度和质量。但除此之外，还有潜在的文化影响：

团队将达成共识。团队会更了解你的工作，除你之外，其他团队成员可以完善代码库的这一部分。
团队将共同承担责任。如果出现问题，不只是某个人的代码需要修复，而是整个团队的代码都需要修复。

任何团队成员都应该能够休上几天假，他几天不工作不会让公司面临风险，也不会因为担心世界末日而不停地去看电子邮件。
个人可以如何改进团队的代码审查流程？如果你是团队主管，不妨开始尝试这些技巧，找出适合你所带团队的方法。
如果你是独立贡献者，可以与主管讨论一下为什么你认为代码审查技术很重要，以及它如何提高效率和帮助团队。
在下次一对一交流或团队会议上，探讨一下这个问题。
参考阅读：
为你推荐【InfoQ6 个实用的 Code Review 实践技巧】InfoQ Pro是 InfoQ 专为技术早期开拓者和乐于钻研的技术探险者打造的专业媒体服务平台。