InfoQ6 个实用的 Code Review 实践技巧( 二 )

显然，这里的问题在于目标不清晰，团队没有收集到足够的反馈就直接构建解决方案。如果在第一步后，我们先画一幅汽车的草图，并将其展示给用户，他们会问相同的问题，这样就可以进一步了解客户需求。如此，就为我们节省了 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 ，而不是完成初稿后，等上几天（已经去忙其他的事），然后最后再返回头来处理反馈意见。
专注代码，而不是人专注于代码，而不是人，这条实践谈的是人与人之间的沟通方式和关系。从根本上讲，这是提倡我们尝试把注意力集中在如何改进产品上，避免作者将评审意见当作对他个人的批评。