LinkedIn 的高效代码审查技巧

LinkedIn 最近通过了进行 100 万次代码审查的里程碑。社交网络服务工具的负责人在此过程中分享了一些经验教训。

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

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

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

多年来，我们已经磨练了几种最佳实践和技巧，以了解如何提供真正出色的评论。以下是我们建议以问题形式提出的一些指南，以帮助确保审阅者和被审阅者从代码审阅中获得最大价值。

我了解“为什么”吗？

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

我是否给予正面反馈？

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

我的 Code Review 评论解释得好吗？

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

我感谢提交者的努力吗？

无论结果如何，努力工作总是需要得到赞赏——这会培养强大、积极进取的团队。一些代码更改不是最高质量的，需要返工。在这些情况下，重要的是仍然承认作者为更改所做的努力，即使他们的代码需要修改。表示感谢的最佳方式是通过提供高质量的反馈和体面的解释、承认好的想法（每次提交的代码中总是有好的东西！）并使用“谢谢”来表达对代码的审查。

这条评论对我有用吗？

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

 

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

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

我的评论太迂腐了吗？

一些代码审查有太多评论，以至于重要的问题——真正需要修复的问题——被次要的建议淹没了。对于给定团队来说，过于注重细节的评审会减慢评审周期，并导致评审者和被评审者产生摩擦。拥有明确的审查期望、示例审查和积极、邀请的审查文化是避免冗长、令人筋疲力尽的审查周期的好方法。

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

在 LinkedIn，我们从过去的一百万次代码审查中学到了很多，我们渴望从下百万次中学到更多。在代码审查中投入的精力越多，团队进行出色代码审查的能力就越好，签入的代码质量就越高，构建的产品质量也越高。高质量的代码审查具有传染性！