代码审查，有时称为代码质量保证，是在您编写代码后让其他人检查您的代码的做法。

　　代码审查为编写和交付软件的过程带来了许多好处：

　　1、通过您的代码库确保一致性。

　　2、教授所有评审成员（帮助知识转移）。

　　3、建立有关可能影响团队其他部分的上下文意识

　　4、有助于避免破坏构建

　　5、重新审视代码更改，以搜索更改中的优化和简化。

　　6、提高质量并帮助确保没有人忘记或错过任何东西。

　　谷歌在其GitHub上有 1,918个跨多种语言的存储库，甚至更多不是开源的。

　　他们的代码库之一由超过 25,000 名 Google 员工共享，通常每天有40,000 次提交（16,000 次人工更改，24,000 次由自动化系统进行）。在高峰时段，它每天必须每秒处理大约 800,000 个查询。

　　谷歌已经发布了他们的工程实践，所以让我们看看他们如何在他们的规模上审查代码，每天有这么多的提交。

　　Google 将其代码库中的更改称为代表更改列表的CL 。它只是一个正在审核的工作单元/一段代码。

　　如何准备代码审查

　　首先，在您考虑代码审查过程之前，请尝试关注谁将进行审查。尝试选择主题专家。选择熟悉此代码库或代码库区域的人。

　　有时这甚至可能意味着让不同的人审查代码的不同部分。但在 Google 中，只有不到 25% 的代码审查人员拥有一名以上的审查人员。

　　让某人及时回应也很重要。为避免瓶颈和个人负担过重，只需 CC 审阅者进行更改，以便在他们方便的时候对其进行审阅。

　　如何运行快速代码审查

　　代码审查应该很快完成。审核的最长时间应为一个工作日。

　　为什么这么急？我个人的QA有时需要数周或更长时间。

　　它变成了一个拦路虎。尽管代码的作者开始着手新工作，但新的更改开始形成积压，并且延迟可能长达数周或数月。

　　开发人员感到沮丧。如果审阅者要求进行重大更改，但每 3 天才回复一次，那么对进行该更改的开发人员来说是令人沮丧的。但是通过快速响应，每当您需要解释您需要做什么时，挫败感就会消失。

　　代码质量会下降。如果你的评论总是很慢，开发人员不太可能进行代码清理、重构工作或一般代码改进（“如果我的评论者 4 天不回复还有什么意义？”），并且提交的代码质量在评论更有可能下??降。

　　代码审查速度快的主要原因是它们很小。与其发送 1,000 行CL，不如将它们分成多个 CL——例如，推送100 行的10个较小的更改。

　　谷歌也有紧急情况，必须快速更改代码以解决生产中的主要问题。在这些情况下，代码质量会放宽。这篇评论应该立即成为审稿人的第一要务。如果你好奇的话，这里有一些谷歌遇到的紧急情况的例子。

　　谷歌的代码审查标准

　　谷歌强调的关键规则是：

　　一旦确实改善了整体代码的健康状况，审阅者通常应该批准更改，即使它并不完美。

　　谷歌似乎提出的关键点是完美的代码不存在。如果它变得更好，那就足够了。

　　这绝对是一种在变得更好和它可以变得更好之间的平衡行为。如果您可以添加更多反馈以进行重大改进，则可能需要对代码进行更多工作。

　　Google 员工在代码审查中寻找什么

　　在进行代码审查时，谷歌会根据他们的工程实践文档关注这些元素：

　　设计：代码是否经过精心设计并适合您的系统？此更改属于您的代码库还是库？它是否与您系统的其他部分很好地集成在一起？

　　功能：代码的行为是否符合作者的预期？代码的行为方式是否对用户有利？大多数情况下，我们希望开发人员对 CL 进行足够好的测试，以便在进行代码审查时能够正常工作。

　　复杂性：代码可以更简单吗？将来遇到此代码时，其他开发人员是否能够轻松理解和使用此代码？它是否针对当前的用例进行了过度设计？

　　测试: 代码是否有正确且设计良好的自动化测试？当代码被破坏时，测试真的会失败吗？他们会开始产生误报吗？每个测试是否做出简单而有用的断言？

　　命名：开发人员是否为变量、类、方法等选择了清晰的名称？

　　评论：评论是否清晰有用？确保明智的评论在哪里解释了为什么要做某事，而不是如何做。

　　风格和一致性：代码是否遵循我们的风格指南？

　　文档：开发者是否也更新了相关文档？

　　谷歌有多种语言的风格指南，如C++、Swift、HTML/CSS、Lisp、JavaScript等。

　　拥有一个每个人都可以参考的文档有助于规范代码。它还有助于澄清审查过程中的期望。

　　Google 员工如何审查代码

　　在 Google 的工程实践中，代码审查分为三个阶段。如果您要复习，以下是您需要涵盖的内容列表：

　　1、获得更改的高级概述

　　2、检查变更的主要部分

　　3、以合理的顺序浏览其余代码

　　让我们更详细地了解每个步骤。

　　1. 获得代码更改的高级概述

　　查看代码更改的描述/摘要。这一切都有意义吗？例如，如果有人正在更改下周将被删除的代码库，请礼貌地推迟更改，并解释为什么看起来不再需要更改。

　　如果人们把时间花在实际上 不需要的工作上，那就是低效的，所以看看你的开发生命周期，看看为什么会发生这种情况。越早发现这些问题越好。

　　为了获得代码的高级概述，您可能需要简要扫描代码组件以了解它们如何协同工作。

　　如果您发现严重的架构问题或重大错误，您应该在此阶段立即分享您的观察结果。即使您没有时间查看评论的所有其他元素。如果架构问题足够严重，审查其余部分甚至可能会浪费时间。

　　除此之外，您应该立即发送评论意见有两个主要原因：

　　A、Google 员工通常会通过电子邮件发送更改，然后根据该更改立即开始新工作。如果审查中的变化需要进行重大调整，他们可能会建立在需要进行重大改变的基础上。

　　B、对 CL 的重大更改可能需要一段时间才能完成。开发人员都有最后期限，通过让他们尽快开始返工来尝试帮助他们满足他们的要求是很有礼貌的。

　　2. 检查代码更改的主要部分

　　一旦你有了一个概述，回顾一下变化的“主要”部分。

　　查找对CL至关重要的一个或多个文件。通常，有一个文件的更改数量最多，它是 CL 的主要部分。

　　将大部分精力花在查看这些作品上。这为所有较小的部分提供了上下文，并且通常可以更快地查看。

　　如果 CL 对您来说太大而无法获得良好的概览和理解流程，这是一个很好的迹象，开发人员应该将他们的 CL 拆分为较小的更改。

　　3. 以合理的顺序查看代码的其余部分

　　一旦您对更改有了一个很好的概述，就可以深入了解细节并逐个文件进行检查。

　　每个审阅者通常会以不同的方式执行此操作。有些按照版本控制呈现给他们的顺序进行，有些则选择特定的顺序。选择对你有意义的。重要的是要回顾一切，不要错过任何事情。

　　审查每一行代码

　　不要错过或略读重要的细节。有时可能会有配置文件或生成的代码，您可以简单地扫描以查找异常情况。但是你在这里的工作是非常彻底和仔细地检查代码。

　　确保您考虑错误、竞争条件、替代方法、简洁性、可读性等。

　　如果你看不懂代码，很可能其他开发人员也无法理解，应该要求开发人员澄清。

　　了解上下文

　　通常，版本控制软件只会显示更改的行。但重要的是阅读前后的行或整个文件，以确保您准确了解所做的更改。

　　您可能只会看到有人if在更改中添加了 2 个以上的块。但是，如果您查看上下文，您可能会看到该if else块现在有 15 个不同if的 ' 。然后你可以拒绝代码更改并适当提高这方面的代码质量，而不是让它变得更糟。

　　请记住，代码降级是缓慢发生的，每次更改都会发生。我们的主要目标是确保质量趋势始终如一，我们永远不会倒退。

　　Google 员工如何编写代码反馈

　　谷歌有一些特定的部分介绍了如何礼貌和尊重地进行代码审查。这并不反对尽可能清楚地为开发人员提供帮助。这里的黄金法则是对代码而不是开发人员进行评论。

　　该怎么办：

　　询问原因：如果不清楚作者为什么以某种方式做事，请随时询问他们为什么做出特定更改。不知道是可以的，问“为什么”会留下一个书面记录，这将有助于将来回答这个问题。（有时，“我很好奇，你为什么决定这样做？”可以帮助作者重新考虑他们的决定。）

　　找到一个结局：如果你喜欢整洁的东西，那么很容易一遍又一遍地检查代码，直到它完美为止，然后把它拖出比必要的更长的时间。不过，这对接受者来说是致命的。请记住，“LGTM”并不意味着“我保证我不朽的灵魂永远不会失败”，而是“我觉得很好”。如果它看起来不错，请继续。（这并不意味着您不应该彻底。这是一个判断电话。）如果需要进行更大的重构，请将它们移至新的 CL。（来源）

　　不该做什么

　　不要使用极端或非常消极的语言：无论是关于你正在审查的更改还是关于周围的代码，请不要说“没有理智的人会这样做”或“这个算法很糟糕”之类的话。虽然它可能会恐吓被审查者去做你想做的事，但从长远来看这并没有帮助——他们会觉得自己无能为力，而且那里没有太多信息可以帮助他们改进。“这是一个好的开始，但它可能需要一些工作”或“这需要一些清理”是更好的表达方式。讨论代码，而不是人。

　　请记住，代码审查有时会倾向于发现问题或与代码讨论而不是表扬。

　　如何处理代码审查中的回退

　　有时，接受审查的开发人员可能不同意您提出的更改。这是如何处理的。

　　考虑他们可能是对的

　　有时开发人员更接近代码及其工作方式，他们可能是对的。如果是，请从该讨论点继续，并保留该代码原样。

　　但如果他们不是，或者他们误解了什么，你应该坚持改变。回应开发人员最初对您提出的挑战，并礼貌地解释您的推理。

　　代码质量改进往往发生在小的增量步骤中，审查是它发生的一种方式。坚持代码改进，即使这对开发人员意味着额外的工作。

　　尽量避免“我稍后会解决这个问题......”

　　审查中最常见的问题之一不是人们不同意代码更改是否有必要，而是他们想在不同的票证下进行或稍后再做。因此，如果您通过此审查，他们向您保证，他们将在稍后跟进并解决问题。

　　一般来说，以后跟进的情况很少发生。这并不意味着开发人员或他们的职业道德有问题。但是很容易忘记，改变优先级，甚至只是迷失在他们的工作队列中。

　　坚持现在就完成工作。合并您必须立即修复的代码库中的更改并没有真正的奇妙收获。您只是增加了可能会在以后跟进或可能被遗忘的技术债务。稍后修复大量票是降低质量的简单方法。

　　唯一的例外是紧急情况，它涉及谷歌处理严重错误的最??高优先级错误。这可能是服务中断，或者在生产中导致人们页面崩溃的错误。

　　自然会渴望尽快合并更改，并且审查可能会接受稍低的质量，并立即编写后续修复。要点是第一个更改消除了紧急情况，第二个更改正确修复了它。

　　结论

　　我希望这已经解释了谷歌在他们的代码审查过程中使用的一些有用的概念。我写这篇文章是为了更好地把它牢牢记住，并对其他公司如何处理 QA 流程感到好奇。