LinkedIn 高效代码审查的技巧

英文原文：LinkedIn's Tips for Highly Effective Code Review - The New Stack

LinkedIn最近（2017）完成了 100 万次代码审查这一里程碑。社交网络服务工具负责人分享了一些在此过程中学到的经验教训。

 阅读和审查代码是每个工程师每天都会做的事情。然而，正式的代码审查流程有点不同——它要求每个代码更改在代码投入生产之前都由另一位团队成员正式审查。在 LinkedIn，自 2011 年以来，代码审查一直是我们开发流程的强制性组成部分。我们要求代码审查的目标是尽可能顺利地扩展我们快速增长的工程团队。良好的代码审查和有意义、有用的注释确实可以帮助提升整个工程组织的水平。在 LinkedIn，这些评论已成为质量保证和知识共享的重要组成部分。拥抱代码审查在几个关键方面使我们的整个工程文化变得更好。

实施全公司代码审查的最大好处之一是提高了我们开发工作流程的标准化。LinkedIn 的每个团队都使用相同的工具和流程进行代码审查，这意味着任何人都可以帮助审查或为另一个团队的项目贡献代码。这消除了诸如“我可以修复他们代码中的错误，但我如何构建该代码并提交修复程序？”之类的问题。反过来，这有助于增强工程组织中不同团队之间的协作。

通过将代码审查作为强制性流程，我们还帮助在公司培养了健康的反馈文化：工程师愿意在所有工作领域提供和接收反馈，而不仅仅是编码方面，因为它已成为工作的常规组成部分。我们的工程师不会将代码审查视为批评或负面的，而是将给予和接受代码审查视为专业成长的机会。事实上，高质量的代码审查是 LinkedIn 晋升过程的重要组成部分，因为它们提供了工程技能的客观证据。

多年来，我们已经磨练了一些关于如何给出真正精彩评论的最佳实践和技巧。以下是一些以问题形式出现的指南，我们建议您询问这些指南，以帮助确保审阅者和受审者从代码审阅中获得尽可能大的价值。

我明白“为什么”吗？

为了促进尽可能最佳的审查并帮助您的团队扩展规模，每个代码更改提交都应包含一个设计概述，简要解释更改背后的动机。当需要从代码更改本身推断理由时，确实很难提供高质量的代码审查。在尝试进行代码审查之前，询问并期望提交者解释他们的动机是公平的。这也鼓励提交者在提交消息中进行解释，从而提高代码文档的质量。

我是否给出了积极的反馈？

在一个充满聪明人的组织中，干净的代码和整洁的测试覆盖率可以被认为是理所当然的。因此，代码审查反馈往往只关注代码中发现的problems和issues。这是非常不幸的，因为大多数人都需要积极的反馈来感到投入和积极——工程师也不例外。当审阅者在代码中看到好的东西时，他们应该指出并给出积极的反馈。这有助于提高团队活力，而且这种积极的反馈往往具有感染力。与所有代码审查评论一样（更多内容见下文），任何积极的反馈都应该是具体的，解释为什么特定的代码写得很好。

我的代码评审评论解释得好吗？

无论反馈是积极的还是消极的，任何代码审查评论都应该是不言自明的。对于评审者来说看似显而易见的事情，对于收到解释不清的代码评审意见的工程师来说可能是不清楚的。如有疑问，最好过度解释，而不是提供简洁的反馈，否则会产生更多问题并需要更多的来回沟通。解释可以很简单，例如“减少重复”、“提高覆盖率”或“使代码更易于测试”。除了使审阅者的评论更加清晰之外，这些类型的解释还有助于强化团队渴望满足的设计原则。

我感谢提交者的努力吗？

无论结果如何，努力工作总是需要受到赞赏——这可以培养强大、积极主动的团队。一些代码更改的质量不是最高的，需要重新设计。在这些情况下，重要的是仍然要承认作者在更改中付出的努力，即使他们的代码需要重新编写。表达赞赏的最好方法是在代码审查中付出努力，提供高质量的反馈和适当的解释，承认好的想法（每次提交的代码中总是有好的东西！），并使用“谢谢”。

此评论对我有用吗？

提出这个问题是验证代码审查注释是否必要的一种简单而有效的方法。归根结底，工程师应该将代码审查视为有用的开发工具，而不是不重要的忙碌工作的来源。如果您认为某条评论对您没有用，请将其删除。无用的代码审查注释的一个典型例子是与代码格式相关的注释。代码风格和格式应该由自动化工具而不是工程师来验证。

“测试完成”部分是否足够彻底？

在 LinkedIn，每个代码更改提交都有一个必须填写的“测试完成”部分。在开源世界中，以GitHub为例，工程师可以在拉取请求描述中提交“测试完成”信息。“测试完成”中应该包含哪些内容取决于更改的严重程度和当前的测试覆盖率水平。如果更改包含新的或更改的条件复杂性，则可以公平地期望单元测试中涵盖它。如果集成测试覆盖率不足，某些更改可能需要运行手动测试。在这些情况下，“测试完成”应包括有关测试场景和输出的信息。当更改改变程序的输出时，将新输出包含在“测试完成”部分中非常有用。

我的评论是否过于迂腐？

有些代码审查有太多评论，以至于重要的问题（真正需要修复的问题）被不太重要的建议淹没了。对于给定团队来说，过于注重细节的评审可能会减慢评审周期，并给评审者和被评审者带来摩擦。拥有明确的审核期望、示例审核以及积极、有吸引力的审核文化是避免冗长、令人疲惫的审核周期的好方法。

总之，拥有正式的代码审查流程有助于提高代码质量、团队学习和知识共享。当团队中的每个工程师都意识到两件重要的事情时，工作质量就会提高：其他人会阅读我的代码，所以它最好是好的，并且我必须解决收到的任何审查意见，所以我应该尝试编写我的代码第一次很好，可以节省以后的精力。当代码审查成为一种日常习惯时，团队就会每天练习提供和接收反馈。这是成长和进步的关键。

在 LinkedIn，我们从过去一百万次代码审查中学到了很多东西，并且我们渴望从下一个百万次中学到更多。在代码审查上投入的精力越多，团队就越能提供出色的代码审查，签入的代码质量就越高，所构建的产品的质量也越高。高质量的代码评审是具有感染力的！