6 个实用的 Code Review 实践技巧

• 你将一个包含大约 1000 行新代码的 Pull Request 提交评审；

• 你收到两条关于 code style 的评论，以及一个关于评审人表示他看不懂这些代码用途的问题；

• 你修复 code style 并回答评审人的问题，然后评审人通过你写的代码；

• 你把代码分支合并到 Master，双眼紧闭，紧握着拳头，紧咬牙关等待着结果。几分钟后，CI 完成。幸好，Master 没有崩溃。然而…

• 此后 6 个月，你一直战战兢兢，不知道代码何时会崩溃，以及以什么方式崩溃。

你可能经历过上述噩梦般的经历，那我们谈谈怎样改进这个流程吧！

实用的 Code Review 实践

在 Shopify，我们看重交付速度、学习以及长期发展。这些价值观虽然有时会产生冲突，但却引导我们不断尝试许多新技术，并推动团队变革。

我在本文总结了一系列 Shopify 内部使用的实用技巧。借助这些技巧，我们能交付经得起时间考验的有价值的代码。

术语说明：我们将 Pull Requests（PR）定义为合并到基础分支前进行 code reviews 的一个工作单元。Github 和 Bitbucket 的用户对这个术语很熟悉。

将 Pull Request 拆分为较小的代码段

这个方法很简单，可以成为提高 code reviews 工作流程最有用的技术。它之所以有效，主要有两个原因：

• 评审人心理上更容易接受开始和完成一小块代码的评审工作。更大的 PR 自然会让评审人推迟和拖延评审，并且在评审过程中被打断的可能性更大。

• 作为一名评审人，如果 PR 太长，就很难深入进去。要检查的代码越多，我们越需要耗费更多脑力来理解整个代码块。

将 PR 拆分为更小的代码段，让你有更多机会在更短时间内得到更深入的评审。

目前，我们无法设置一个适用于所有编程语言和所有类型工作的通用标准。对于内部的数据工程项目，我们原则上是要将 PR 控制在 200-300 行代码。如果超过这个阈值，我们一般会将它拆分成更小的块。

当然，我们也要注意不要将 PR 拆分得过小，因为这意味着评审人可能需要检查好几个 PR 才能理解整体逻辑。

使用 Draft PRs

你听过造一辆汽车与画一辆汽车的比喻吗？这个比喻是这么说的：

• 用户要你造一辆车；

• 6 个月后，你造了一辆漂亮的保时捷；

• 你向用户展示这辆车后，他们问你这辆车能不能放得下他们的 5 个孩子和冲浪板。

显然，这里的问题在于目标不清晰，团队没有收集到足够的反馈就直接构建解决方案。如果在第一步后，我们先画一幅汽车的草图，并将其展示给用户，他们会问相同的问题，这样就可以进一步了解客户需求。如此，就为我们节省了 6 个月的工作量。软件也不例外，我们可能会犯同样的错误，在用户不需要的特性或模块上投入大量工作。

在 Shopify，一般用 Work In Progress (WIP) PRs 来获得早期反馈，其目标是验证方向（算法、设计、API 等等选择）。尽早变更可以避免在细节、修饰、文档等方面浪费精力。

作为一名写代码的人，这意味着你要对变更工作方向持开放态度。

在 Shopify，我们信奉的原则是允许大家有自己的理解，但不固执己见。我们希望大家能在有充足理由的情况下自信地做出决定，但同时也能乐于学习其他更好的新方案。在实际工作中，我们使用 Github 的 Draft PRs，它们明确表明这项工作仍在流程中流转，Github 不允许你合并一个 Draft PR。其他工具可能有类似的功能，至少你创建正常 PR 时可以加上一个 WIP 标签，以明确表示该工作还处于前期阶段。这将帮助你的评审人专注于适当的领域，提出适当的反馈。

One PR Per Concern

除了行数外，需要考虑的另一个维度是你的工作单元试图解决的问题数量。一个关注点可以是一个特性、一个错误修复、一个依赖项升级、一个 API 变更等等。你是否在重构的同时引入一个新特性？一次修复了两个错误？同时引入了类库升级和新的服务？

• 把 PR 分解为一个个单独的关注点，它会产生下列影响:

• 更独立的评审单元，这意味着更好的审查质量；

• 受影响的人更少，因此可以聚集在更少的几个专业领域中；

原子性回滚，可以回滚小的 commit 或 PR。这是很有价值的，因为如果出了问题，就更容易确定错误是在哪里引入的，以及回滚哪些部分。

将易事和难事分开。假设有一个新特性，需要重构一个频繁使用的 API。你可以更改这个 API，升级十几个调用的站点，然后实现这个特性。你的变更中有 80% 不是功能上的变更，明显可以忽略掉，而 20% 是需要仔细注意测试覆盖率、预期行为、错误处理等等的新代码，并且可能要经过多次修订。对于每一个修订，评审人都需要浏览所有的修改以找到相关的部分。通过将其分成两个 PR，很容易就可以快速完成大部分工作，并优化评审工作，将主要精力投入到难点上。

如果你最终拿到手的 PR 包含多个关注点，那么你可以将其分解为多个单独的块。这样能针对每一块进行单独的评审，每次评审的迭代周期可以更快，从而加速这个 PR 的总体评审周期。通常情况下，有一部分工作能先快速完成，避免代码烂到不能用以及引起合并冲突。

将 PR 分解成单独的关注点

上例的 PR 包含三个不同的关注点，我们将其进行拆分。可以看到，每个评审人需要检查的上下文少了许多。最重要的是，只要其中任何一个部分的评审完成，代码作者就能一边等待其他评审反馈，一边着手处理已经反馈的问题。在最极端的情况下，代码作者会陆续收到各个部分的评审反馈，几乎可以不间断地处理完这一系列 PR，而不是完成初稿后，等上几天（已经去忙其他的事），然后最后再返回头来处理反馈意见。

专注代码，而不是人

专注于代码，而不是人，这条实践谈的是人与人之间的沟通方式和关系。从根本上讲，这是提倡我们尝试把注意力集中在如何改进产品上，避免作者将评审意见当作对他个人的批评。

以下是一些你可以遵循的技巧：

• 评审人可以这样想：“这是我们自己的代码，我们该如何改进它呢？”

• 提出肯定意见！如果你看到有些代码部分写得不错，就加条评论表扬一下。这能让代码作者继续保持好的一面，并有助于他在心理上更容易接受改进建议。

• 代码作者不妨这么想，评审人的出发点肯定是好的，不要将评论当作是对个人的批评。

• 下表列出了一些存在不足的评审反馈，以及如何按以上建议进行重写的建议。

归根结底，code review 给我们提供了互教互学的机会，我们应该对此持开放欢迎的态度。

挑选合适的评审人

• 决定由谁来评审你的工作通常很有挑战性。以下问题可作为参考：

• 谁具备你正在构建的特性或组件的上下文？

• 谁精通你正在使用的语言、框架或工具？

• 谁对这一主题知之甚深，有自己的理解？

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（资料价值较高，非无偿）

总结

上述知识点，囊括了目前互联网企业的主流应用技术以及能让你成为“香饽饽”的高级架构知识，每个笔记里面几乎都带有实战内容。

很多人担心学了容易忘，这里教你一个方法，那就是重复学习。

打个比方，假如你正在学习 spring 注解，突然发现了一个注解@Aspect，不知道干什么用的，你可能会去查看源码或者通过博客学习，花了半小时终于弄懂了，下次又看到@Aspect 了，你有点郁闷了，上次好像在哪哪哪学习，你快速打开网页花了五分钟又学会了。

从半小时和五分钟的对比中可以发现多学一次就离真正掌握知识又近了一步。

人的本性就是容易遗忘，只有不断加深印象、重复学习才能真正掌握，所以很多书我都是推荐大家多看几遍。哪有那么多天才，他只是比你多看了几遍书。

《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门即可获取！
3gcd7-1711569931952)]

人的本性就是容易遗忘，只有不断加深印象、重复学习才能真正掌握，所以很多书我都是推荐大家多看几遍。哪有那么多天才，他只是比你多看了几遍书。

《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门即可获取！