如何审查你看不懂的代码

我最近读了 Max Bittker 的一篇文章，题为“如何审查你不理解的代码”，这让我回想起自己曾经被要求做这件事的经历。

代码审查中我遇到的一个难题是理解代码变更的上下文。拿到差异文件后，我可以逐行分析，大概能理解大部分内容。至少，我能理解其运行机制。但这和理解代码想要实现的目标是一样的吗？我认为不是。

自从成为开发人员以来，我在阅读代码时遇到的一个难题是，无论我看到什么，我看到的都是解决方案，而不是问题本身。事实上，我看到的只是一个特定的解决方案，也就是我需要审查的那个方案。

在代码审查时，我希望提出有见地的建议，学习新知识，并发现我能看到的错误。（在 Ruby 中，90% 的时间我都在问“嘿，这里需要做空值检查吗？”）。

那么，当我只能看到（通常）一位开发者的理解、问题解决过程和个人风格的成果时，我该如何做到这一点呢？这很难——可以说是我的工作中难度最大的部分之一。由于缺乏大量的代码注释，或者在我阅读代码时缺乏某种形式的讲解（想象一下——就像代码的导演解说一样），所有这些重要的背景信息都会丢失。

假设我们不会彻底改革团队的流程，也不会从头开始构建更好的代码审查工具，那么为了改善代码审查体验，我们明天可以在工作中采取哪些措施呢？

请提交者审核代码

如果你的同事还没有进行代码差异自检并添加内联注释，请他们这样做。这将提供一些宝贵的见解——他们为什么做出某个选择，遇到了哪些困难，以及为什么某些部分看起来过于复杂。他们可能会指出希望审阅者重点关注的特定区域，或者指出他们对自己决策感到不确定的地方。这有助于我们初步了解开发者编写代码时的思路。

努力理解开发者想要达到的目标。

如果你的工作场所和我的一样，你可能会以拉取请求、用户故事、一些模型以及围绕这项工作的更大背景的一般想法来开始代码审查。

然而，我们生活在一个并不完美的世界。用户故事或许会比较模糊（我还没见过哪个团队能写出完美无瑕的用户故事）。或许没有原型图，或许你对相关背景也不太了解。

所以在继续之前，先努力理解。

关键在于要掌握足够的理解力。有时候，新闻稿或公关稿的描述可能过于宽泛。

例如，您可能知道总体目标是在用户的发票 PDF 上显示其地址。很好，这段代码就是要实现这个目标，对吧？

你可能不知道，用户的地址信息属于其他服务，而你正在使用的应用需要请求该信息。因此，开发者必须考虑分布式事务、数据完整性以及如何优雅地处理 HTTP 请求失败。或许他们已经考虑过这段代码应该放在哪里，并从几个选项中选择了一个。

你需要问一些问题才能获得足够的背景信息。

“你采取了什么样的方法？”这是一个可以问同事的好问题。“你是否尝试过其他方法但最终放弃了？”也是一个不错的问题。

后续问题可以探讨他们所做的权衡取舍。如果你是开发新手，这听起来可能有点吓人，但其实不必如此。“为什么？”是一个很好的后续问题。甚至可以尝试一下“5个为什么”分析法。

无论如何，养成在审查拉取请求之前提出问题的习惯。

自行通读代码*

结合提交者的自我评估以及你对他们所采用方法的理解，通读代码并添加内联注释。注释可以是问题、给自己的笔记，也可以是给提交者的反馈。

我特别喜欢 GitHub 的一个功能，它可以让你“暂存”所有代码审查笔记，然后一次性提交。这样我就可以自由地给自己写笔记，删除差异分析后面已经解答的问题（RAFO！），并且编辑笔记而不会让提交者收到大量邮件。

如果可能的话，和他们一起检查代码。

最好是当面谈。这样可以解答你的疑问，并讨论对作品的任何修改意见。

这也是讨论其他方法的机会，这实际上又让我回到了我之前关于代码审查的困惑。

当你阅读提交审核的代码时，你看到的只是解决当前问题的一种方案。仅此一种方案。当你只关注这一种方案时，很难考虑其他可能的解决方案。

我发现经验越丰富就越容易，但对于新手开发者，或者审查与他们通常熟悉的领域截然不同的代码的开发者来说，跳出已有的思维模式可能非常棘手。这就像定势效应一样。

如果你在审核一个拉取请求时，发现很难考虑其他方法，请与提交者沟通。问问他们：你有没有考虑过其他方法？是什么方法？

如果结果证明他们没有考虑过其他解决问题的方法，而你也没有想到任何方法，那也没关系。无论如何，养成问这些问题的习惯是件好事。

跟进所有讨论过的更改，然后勾选！

希望通过这种方式，你们双方都能有所收获。或许你们对各自的领域和代码库有了更深入的了解。你和提交者可能讨论过解决问题的不同方法，或者至少花了两分钟时间思考其他方法。干得漂亮😄。

这并非我处理每个 pull request 都会采用的方法。幸运的是，有些 pull request 比其他的要简单直接得多！但如果你发现自己需要审查一个相当庞大的代码，不妨考虑一下这些方法。

如果变更集很大，可以问问提交者能否进一步拆分——不一定非要拆分成多个 PR（虽然如果可行的话这样做也不错），或许他们可以带你了解一下其中的一部分工作，以任何合适的方式。我们真正需要的是一个更好的工具来分析代码差异，但这又是另一个话题了。