目录
关于 LinkedIn 的代码审查的文章，文章以提问题的方式逐一指出代码审查的好处以及一些注意事项，给出建议和一些见解。
下面是我的大致翻译：
翻译
LinkedIn 最近完成了一百万次代码审查的里程碑。社交网络服务工具的负责人在这个过程中分享了一些经验教训。
阅读和复查代码是每个工程师每天都要做的基础事情。然而，正式的代码审查过程有些不同，它要求在代码投入生产之前，每个代码的更改都要需要另一个团队成员进行正式审核。在LinkedIn，从2011年开始，代码审查一直是我们开发过程的必不可少的部分。我们要求代码审查的目标是尽可能顺利地扩展我们快速发展的工程团队。使用有意义的，有用的代码注释可以进行很好的代码审查，进而提升整个工程组织的水平。在LinkedIn，代码审查已成为质量保证和知识共享的重要组成部分。
实施公司代码审查的最大好处之一就是提高了我们开发工作流程中的标准。LinkedIn中的每个团队使用相同的工具和流程进行代码审查，这意味着任何人都可以为其他团队的项目审核或贡献代码。这同时也解决了诸如“我可以修复代码中的错误，但我如何构建代码并提交修复程序？”之类的问题。反过来说，这有也有助于增加组织中不同团队之间的协作。
通过这代码强制性审查的流程，我们还培养了公司良好的反馈文化：工程师可以在所有工作领域提供和接收反馈，而不仅仅是编码方面，因为它已成为了工作的日常。我们的工程师不会将代码审查视作为爱挑剔或者是负面，而是将提供和接收代码审查作为专业发展的机会。而事实上，高质量的代码审查是 LinkedIn 晋升过程中的重要组成部分，因为它客观的展现了工程师的技能水平。
多年来，我们已经磨练了几个最佳实践和技巧，以便提供真正优秀的代码审查方式。以下是以问题形式一些的指导，我们建议获取帮助来确保审核人员和审核人员能够从代码审核中获得最大价值。
我能理解”为什么“吗？
为了促进最佳的审核并帮助团队扩展，每个代码更改提交都应包含一个设计概述，简要说明变更背后的动机。因为当需要从代码本身去推断更改理由时，是很难提供高质量代码审查的。所以在提交代码审查之前，要求或呼吁提交者解释他们提交代码的理由是天经地义的。这同时也鼓励提交者在代码提交消息中进行相应的解释，从而提高代码文档的质量。
我有提供正面反馈吗？
如果组织中都是聪明伶俐的人，那么干净的代码和整洁的测试覆盖率可以被视为理所当然。因此，代码审查反馈往往只关注代码中发现的问题或问题本身。这是非常不幸的，因为大多数人需要积极的反馈才能获得参与感或感受到积极性，工程师也不例外。当审查者在代码中看到好东西时，他们应该调出来并给出积极的反馈。这有助于改善团队活力，并且这种积极反馈往往具有感染性。与所有代码审查注释一样（下面有更多内容），任何积极的反馈都应该具体，解释为什么特定的代码写得好。
我的代码审查注释解释得好吗？
无论反馈是积极的还是消极的，任何代码审查注释都应该是清晰明了的。对于收到那些解释不清的代码审查注释的工程师来说，审查者看起来显而易见的事情可能就变得不明确了。如果有疑问，最好是过度解释而不是提供简洁的反馈，从而产生更多问题，并需要更多来回的沟通。解释可以简单到“减少重复”，“改善覆盖范围”或“使代码更容易测试”。除了使审查的注释更加清晰之外，这些类型的解释还有助于加强团队的设计原则。
我是否感激提交者所做的努力？
无论结果如何，努力工作都需要得到赏识，这可以培养强大且积极进取的团队。某些代码更改的质量不高，需要重新编写。在这些情况下，最重要的是还是首先承认作者为改变付出的努力，即使他们的代码需要重新编写。表达赞赏的最佳方式是努力进行代码审查，并且提供高质量的反馈和正确的解释，期间承认这是好的想法（每个代码提交中始终有好的东西！），并使用“谢谢”。
审查注释对我有用吗？
提出这个问题是验证代码审查注释是否必要的简单而有效的方法。在一天工作结束的时候，工程师应该将代码审查视为有用的开发工具，而不是增加工作量大的罪魁祸首。如果你认为特定审查注释对你没有用，就将其删除。一个无用的代码审查注释的典型示例就是与代码格式相关的注释。代码样式和格式应该由自动化工具验证，而不是工程师。
“测试完成”这部分信息是否足够充足？
在 LinkedIn，每个代码更改提交都有一个强制性的“测试完成”部分，需要填写。在开源中，以GitHub为例，工程师可以在拉取请求描述中提交“测试完成”的信息。“完成测试”应该包括变化的严重程度和当前的测试覆盖率。如果一项变更比较复杂，包含新的或受依赖的变化，则可以在单元测试中对其进行覆盖。如果集成测试覆盖率不足，某些更改可能需要进行手动测试。在这些情况下，“完成测试”应包含有关的测试场景和测试相关的输出信息。当更改程序的输出时，将新输出包含在“测试完成”部分中非常有用。
在审查中，我是否太学术化了？
一些代码审查有很多注释，导致一些重要的问题或者那些正真需要关注的问题就在注释中被埋没。有些团队的审查注释信息可能过多导致减慢审核周期，并且过重的信息可能也会导致审核人员之间的冲突。所以一个有明确的审核期望，示例注释以及积极，有吸引力的审核文化是避免冗长，耗费精力的审核周期的好方法。
总之，有正式的代码审查流程有助于提高代码质量，团队学习和知识共享。当团队中的每个工程师都意识到这两个重要的事情时，工作质量就会提高：首先，其他人会读取我的代码，所以最好是将代码写好一些，其次就是我需要去解决我收到的任何评论意见，所以我应该尝试第一次就将我的代码写好来避免将来“还债”。当代码审查成为日常习惯时，团队就会每天练习提供和接收反馈。这是成长和改善的关键。
在LinkedIn，我们从过去的一百万次代码审查中学到了很多东西，我们希望从下一个百万代码中学到更多。代码审查所付出的努力越多，团队提供的代码审查质量就越好，合格的代码质量就越高，产品的质量也就越高了。所以高质量的代码审查是具有传染性的！
作者感谢James Miller，Oscar Bonilla，Joshua Olson，Andrew Macleod，Scott Meyer和Deep Majumder对本文的深刻反馈。
生词
mandatory：adj. 命令的;强制的;义务的
implement：vt. 使生效, 贯彻, 执行； n. 工具, 器具, 用具
eliminates：vt. 消除, 排除；忽略；淘汰；〈口〉干掉
foster：vt. 养育，抚育；培养；抱（希望等）；adj. 收养的，养育的
promotion：n. 提升,晋级；宣传;推销
honed：n. 爱人
facilitate：vt. 使便利, 减轻…的困难
engage：vt. 雇佣；吸引，占用；使订婚；使参加；预定；vi. 答应，保证；从事；交战；啮合
dynamic：adj. 有活力的, 强有力的；不断变化的；动力的, 动态的
contagious：adj. (病)有传染性的；(人)患传染病的；有感染力的
terse：adj. 简洁的，精练的，扼要的
Thorough：adj. 彻底的；十分的；周密的
More：文章中的 Code Review Comment 被我翻译为代码审查注释不知恰当与否，并且第一次尝试翻译英文技术类文章，如有不同观点欢迎指出。
0 条评论