Code Review
LinkedIn’s Tips for Highly Effective Code Review
LinkedIn最近通过了100万次代码审查的里程碑。社交网络服务工具的负责人分享了一些经验教训。
阅读和检查代码是每个工程师每天都要做的事情。 然而，正式的代码评审过程有点不同——它要求在代码投入生产之前，由另一个团队成员正式评审每一个代码更改。 自2011年以来，在领英(LinkedIn)，代码评审一直是我们开发过程中必不可少的一部分。我们要求代码评审的目标是尽可能平稳地扩展快速增长的工程团队。 好的代码评审和有意义的、有用的注释可以真正帮助升级整个工程组织。在LinkedIn，这些评论已经成为质量保证和知识共享的重要组成部分。采用代码评审在几个关键方面使我们整个工程文化变得更好。
实现全公司范围的代码评审的最大好处之一是增加了开发工作流的标准化。 LinkedIn的每个团队都使用相同的工具和过程进行代码评审，这意味着任何人都可以帮助评审或为另一个团队的项目贡献代码。 这消除了诸如“我可以修复他们代码中的错误，但是我如何构建代码并提交修复?”这反过来有助于增加工程组织中不同团队之间的协作。
通过让代码评审成为一个强制性的过程，我们也帮助公司培养了一种健康的反馈文化:工程师们乐于在工作的各个领域提供和接收反馈，而不仅仅是在编码方面，因为它已经成为了工作的常规组成部分。我们的工程师不把代码评审看作是关键的或负面的，而是把提供和接收代码评审作为专业发展的机会。事实上，高质量的代码评审是LinkedIn晋升过程中的一个重要部分，因为它们提供了工程技能的客观证据。
多年来，我们已经磨练了一些最佳实践和技巧，以提供真正伟大的评审。下面是一些指导方针，以问题的形式，我们建议询问它们，以确保审阅者和 reviewee 能够从代码评审中获得最大的价值。
我了解原因吗？
为了促进尽可能最好的评审和帮助您的团队扩展，每一个代码变更提交都应该包含一个设计概述，简要地解释变更背后的动机。 当需要从代码更改本身推断基本原理时，很难提供高质量的代码审查。 在尝试代码评审之前，询问并期望提交者解释他们的动机是公平的。这也鼓励提交者在提交消息中有一个解释，从而提高代码文档的质量。
我给出积极的反馈了吗?
在一个充满聪明的人的组织中，干净的代码和整洁的测试覆盖率可以被认为是理所当然的。 因此，代码评审反馈往往只关注代码中的问题和问题。这是非常不幸的，因为大多数人需要积极的反馈来感到投入和积极，工程师也不例外。 当审查者看到代码中的好东西时，他们应该指出来并给出积极的反馈。这有助于提高团队的动力，通常这种积极的反馈是会传染的。 与所有代码评审注释一样(下文将对此进行详细介绍)，任何积极的反馈都应该是特定的，解释为什么特定的代码编写得很好。
我的代码评论解释得好吗?
无论反馈是积极的还是消极的，任何代码审查评论都应该是不言自明的。对于一个收到解释不清楚的代码评审注释的工程师来说，审查者可能认为很明显的事情是不清楚的。当你有疑问的时候，最好是多解释，而不是提供简短的反馈，这样会产生更多的问题，需要更多的交流。解释可以简单到“减少重复”、“提高覆盖率”或“使代码更容易测试”。除了让评审员的评论更清晰之外，这些类型的解释还有助于强化团队希望达到的设计原则。
我感谢提交者的努力吗?
无论结果如何，努力工作总是需要被赞赏的——这培养了强大的、有高度动力的团队。有些代码更改不是最高质量的，需要重新处理。在这些情况下，重要的是仍然要承认作者在更改中所付出的努力，即使他们的代码需要重写。表达赞赏的最好方式是在代码评审中付出努力，给出高质量的反馈，给出适当的解释，承认好的想法(在每次代码提交中总是有好的东西!)，并使用“谢谢您”。
这篇评论对我有用吗?
问这个问题是验证代码评审注释是否必要的一种简单而有效的方法。在一天结束的时候，工程师应该把代码评审看作是有用的开发工具，而不是无关紧要的工作的来源。如果您不认为某个评论对您有用，那么删除它。无用的代码复查注释的典型例子是与代码格式有关的注释。代码样式和格式应该由自动化工具来验证，而不是工程师。
“测试完成”部分是否足够全面?
在LinkedIn，每一次代码变更提交都有一个必须填写的“测试完成”部分。在开源世界中，以GitHub为例，工程师可以在拉取请求描述中提交“测试完成”信息。在“测试完成”中应该做什么取决于更改的严重性和测试覆盖率的当前级别。如果更改包含新的或修改过的条件复杂性，那么可以期望在单元测试中包含它。如果集成测试覆盖率不足，一些更改可能需要运行手工测试。在这些情况下，“已完成的测试”应该包含关于测试场景和输出的信息。当更改改变程序的输出时，在“测试完成”一节中包含新的输出是非常有用的。
我的评论是不是太迂腐了?
一些代码评审有如此多的注释，以至于重要的问题——那些真正需要修复的问题——在不那么重要的建议中丢失了。对于一个给定的团队来说，对细节过于关注的评审可能会减慢评审周期，并导致评审人员和reviewee之间的摩擦。有清晰的评审期望、示例评审和积极的、诱人的评审文化是避免冗长的、令人筋疲力尽的评审周期的好方法。
总之，有一个正式的代码评审过程有助于提高代码质量、团队学习和知识共享。工作质量的增加,当每一个工程师团队实现两个重要的事情:别人会读我的代码,所以最好是好的,和我得地址我收到任何评论评论,所以我应该试着使我的代码好第一次来拯救自己的努力。当代码评审成为一种日常习惯时，团队就会每天练习给出和接收反馈。这是增长和改善的关键。
在领英，我们从过去100万的代码评论中学到了很多，我们渴望从接下来的100万中学到更多。在代码评审中投入的精力越多，团队就越擅长进行出色的代码评审，检入的代码质量越高，构建的产品质量越高。高质量的代码评审具有传染性!
作者感谢James Miller, Oscar Bonilla, Joshua Olson, Andrew Macleod, Scott Meyer和Deep Majumder对本文的深刻反馈。
LinkedIn的母公司微软(Microsoft)是这个新平台的赞助商之一。
