给予和接受优秀的代码审查

参与代码审查是我职业生涯中最有趣的学习经历之一。我做过一些非常愚蠢的事情，但在过去两年参与的 400 多次代码审查中，我学到了很多东西。代码审查能让你更了解自己和你的代码，今天我很高兴能和大家分享更多相关内容。

那么，代码审查究竟是什么呢？代码审查是指团队讨论和辩论未来将由团队负责维护的代码。团队成员（或部分成员）编写代码，而其他成员或部分成员则负责评估代码是否达到标准，是否能为代码库带来价值。

从更微观的角度来看，代码审查是一个抽象的概念，指的是在完成任务的过程中，对方法和代码进行审查的过程。在我看来，代码审查分为两个截然不同的阶段。

所以你已经花了几个小时甚至几天时间阅读现有代码，理解了代码的内容、数据流向以及需要做的修改。此时你可能已经完成了大约 20% 的工作。接下来，你需要向一位资深工程师提出你的修改方案。首先，他们会尊重你之前所做的工作，不会打扰他们（他们的时间有时很宝贵）；其次，凭借你的知识以及他们可能也具备的知识，他们可以和你讨论你的方案，或许会提出一些小的调整建议，甚至可能要求你重新开始（抱歉，但这种情况我们每个人都可能遇到）。

一旦确定了这一点，就可以开始编写代码了。这就进入了主要的代码审查阶段，此时你已经完成了大约 90%，剩下的只是就代码设计和其他一些事项达成一致。

作为提交者

那么，让我们来谈谈创建优秀拉取请求（PR）的关键技巧，拉取请求是现代代码审查机制。

首先，你的 PR 应该讲述一个故事。你可能花费了大量时间思考，但审核者可能没有。所以，请告诉他们你的思考过程，并描述你为实现目标所采取的逻辑步骤。作为审核者，我会关注两方面：你的提交日志和 PR 描述。

你的提交应该是一个循序渐进的过程。所有代码都应该与其对应的单元测试配对，并且每次提交都应该遵循以下规则：

1. 用空行将主体与身体隔开。

2. 邮件主题字数限制为 50 个字符。

3. 主题行首字母大写

4. 邮件主题不要以句号结尾。

5. 邮件主题请使用祈使语气。

6. 正文长度为 72 个字符

7. 正文应着重解释“是什么”和“为什么”，而不是“如何”。

更多详情请见克里斯·比姆斯博客，建议您阅读。

所以，一旦你有了逻辑清晰的提交，没有了“从 master 合并”、“修复问题”或“尝试一些 fbdifha ahhh”之类的提交，我们就可以开始代码审查了。PS：当你准备好提交时，使用交互式 Git 变基和软 Git 重置可能会有所帮助。

现在来说说PR描述。我认为，这部分应该包含以下内容：

1. 指向您正在解决的原始问题的链接（例如 GitHub 问题、JIRA 工单或其他链接）

2. 思维过程概述

3. 您是如何在本地进行测试的（例如，“我运行了这项服务和 X 服务，并使用 cURL 确认新的请求行为是否按预期工作”）

4. 你认为这个 PR 可能会破坏任何东西（但你已经检查过没有破坏）。

5. 您希望审阅者就哪些具体方面发表意见（例如类名、代码的时间复杂度等）？

完成这些步骤后，代码审查者就能快速上手代码，专注于代码的质量和影响。可以找一位（或许两位）团队成员进行代码审查。尽量选择在编码过程中没有过多帮助过你的人，这样可以让你从全新的视角审视代码。

最后，在提交代码审查之前，请先自行检查。检查一下，我的提交记录看起来是否正确？是否保留了调试代码？是否保留了测试关键字（我通常会保留 RSpec 的焦点关键字）？代码差异是否符合我的预期？这短短 90 秒的检查可以避免审查人员产生大量困惑。

作为审稿人

对于代码审查员来说，我最想强调的一点是：代码审查是一项工作。它能为公司创造价值，虽然这可能不是你的职责，但它仍然至关重要。团队已经认定提交者完成的工作非常重要，需要立即完成，所以你应该认真对待，真正承担起这份责任。

所以，代码审查一定要认真对待。花几个小时审查代码是完全可以的，而且也可以明确指出你正在负责的部分。仓促的代码审查只会将来给你带来麻烦。说不定下一个负责这部分代码的人就是你！

在开始阅读代码之前，务必点击查看提交记录和 PR 描述，以获取更多上下文信息。如果审查者有任何疑问，也请一并解答，并耐心仔细地阅读。如果您不确定代码是否真的能正常运行，请检出分支并尝试按照步骤复现测试结果。记住：如有疑问，请先进行检查。

如果你发现自己在吹毛求疵地纠结于代码风格，请问问自己：为什么代码检查器没有发现这个问题？这是否需要添加一条新规则，或者我是否可以对程序员进行一些指导？记住，代码审查的重点并非那些可以通过SwiftClean、Credo、FindBugs、Rubocop或StyleCop等工具自动检查的内容，所以请确保你的代码已经通过这些工具的检测，并在持续集成 (CI) 环境中运行，一旦发现任何违规，就应该终止构建。

现在，代码审查阶段可以进行几次迭代。新的更改需要结合现有更改进行重新审查，这可能会导致需要进行更多更改。请保持耐心，并鼓励提交者也保持耐心。代码审查也是一个“线下交流”的好时机，可以鼓励使用白板或结对编程的方式，讨论代码中的任何重大缺陷，或者就某些方面进行指导/辅导。理想情况下，同一个人提交的代码审查报告不应该包含相同的缺陷。

以上就是代码审查的内容。总而言之，作为提交者，要做好规划，清晰地阐述代码的来龙去脉，并将审查过程视为学习的机会。作为审查者，要放慢速度，仔细检查，尽可能地自动化代码审查流程，并借此机会提升团队的整体水平。

祝你好运！有什么问题吗？我很乐意听听！

这是我的“初级开发者日记”博客系列的第五篇文章。我每周都会更新，你可以在我的网站上注册，阅读更多内容并阅读之前的文章。