大型团队代码审查的实用技巧

由 Mux 赞助的 DEV 全球展示挑战赛：展示你的项目！

对于旨在维持并提升效率和代码质量的开发团队而言，改进代码审查流程至关重要。不断增长的待处理拉取请求 (PR) 列表可能会让人不堪重负，甚至打击士气。通过优化审查流程，团队可以确保 PR 的均衡分配，避免某些团队成员不堪重负而其他成员却闲置。力求 PR 审查时间的均衡有助于营造和谐的团队氛围。此外，坚持以一个工作日内完成审查为目标的标准，可以确保快速反馈，并促进动态、响应迅速的开发周期。最后，改进的本质在于提升 PR 的质量，确保其大小适中、准备充分且内容全面，从而简化整个开发流程。

如何衡量代码审查的有效性

为了评估代码审查流程的有效性，关键在于关注团队绩效而非个人贡献。关键指标包括拉取请求 (PR) 的审查时长以及 PR 审查阶段所占代码行数的比重。监控未关闭的 PR 数量以及每个 PR 中的代码量，可以进一步深入了解审查流程的效率。

衡量的是团队的整体效能，而不是某些人的效能。
测量 PR 处于审核状态所需的时间。
计算 PR 处于审核状态的时间，除以代码行数。
处于开放状态的 PR 数量。
PR 中的代码行数

这可以通过引入收集 PR 信息的工具来实现。如果您使用 GitHub，可以使用 GitHub Action 的issue-metrics功能来衡量 PR 在特定时间段内的平均审核时长。当然，您也可以使用 GitHub API 创建自定义 Action，用于收集对项目至关重要的信息。

准备好你的公关稿

提交 PR 时，务必先添加详细的描述。如果可视化有助于理解，可以考虑添加图表。制定审查计划也至关重要，它可以引导审查人员按照逻辑顺序进行审查，确保不会遗漏任何更改。
在请求他人深入研究代码之前，请先自行浏览 PR 草稿。这种自我审查可以帮助您发现并清理任何无关的注释或疏漏。PR
中的注释应该阐明您的编码决策，尤其是在可能造成混淆的情况下。例如，如果您在当前的 PR 中修复了一个不相关的 bug，请务必提及。这种预先的澄清可以避免审查人员长时间的困惑。注释就像一张路线图，清晰地展示了您的更改。通过引导审查人员查看特定文件或解释某些修改背后的原因，您可以简化他们的工作。此外，您还可能在注释阶段发现错误，并在审查开始前进行修复。
如果您在一个 PR 中解决了多个问题，则可能需要将其拆分。PR应该简洁明了，重点突出。一条经验法则：如果一项更改涉及五个以上的文件、耗时超过一天撰写，或者需要大量的审核时间，那么就将其拆分。例如，一个 PR 可以阐述新功能的 API，而后续的 PR 则可以介绍具体的实现方式。

如何审核他人的PR

对待代码审查要像对待其他任何任务一样认真。在日历中专门预留固定的时间段进行代码审查。及时反馈至关重要——开发人员等待的时间越长，对上下文的理解就越模糊，也就越难采纳建议。
代码审查不仅仅是为了发现 bug，它还提供了一个让你熟悉团队不断发展的功能和编码原则的机会。抓住这个学习和成长的机会。
你在审查过程中的评论应该清晰且具有建设性。含糊不清的评论会导致困惑。始终致力于提供能够引导开发人员找到预期解决方案的反馈。
虽然像 GitHub 这样的平台非常适合代码托管和初步审查，但它们可能并不适合进行长时间的讨论。考虑将长时间的对话转移到像 Slack 这样的平台上，以便进行更动态的交流。
对于大量的 pull request，将分支拉取到本地开发环境中会很有帮助。像IntelliJ IDEA这样的工具可以提供更沉浸式的差异视图。记住使用类似 `diff` 这样的命令git merge -no-commit -no-ff来查看更改，就像你自己做的一样。

如果你觉得代码的某些部分难以理解，请毫不犹豫地直接向作者请教。与其基于臆测提供反馈，不如停下来仔细理解。

审稿人分配算法

自动为 PR 分配审阅者有多种方法，例如随机分配或使用矩阵分配。GitHub 提供了两种策略（https://docs.github.com/en/organizations/organizing-members-into-teams/managing-code-review-settings-for-your-team#about-auto-assignment
）。另一种方法是采用自定义策略，每个团队成员都拥有一份来自其所在小组的审阅者列表，以及来自其他小组的两名临时审阅者。
根据团队规模和功能交付速度，选择最适合您团队的方法。

代码审查的速度

虽然即时审查是理想之选，但并非总是可行。不过，一条黄金法则是：24 小时内回复。即使只是初步评估，也要力争在一个工作日内回复代码审查请求。这可以确保代码不会长时间处于审查停滞状态，从而避免延误后续开发阶段。
遵循这条法则，一个典型的变更列表 (CL) 很可能在必要时于一天内完成多轮审查。这种快速的响应不仅简化了开发流程，还有助于审查者和开发人员之间进行动态讨论，从而打造出更完善的代码库。

如何处理评论

与其仅仅依赖 GitHub 评论，不如使用Slack GitHub 连接来促进 PR 的沟通。它提供了一个动态的实时互动平台，方便澄清疑问、寻求解释，并就建议的更改达成共识。
如果您计划稍后处理某个评论或问题，请添加TODO标签并附上任务编号。这可以确保您拥有清晰的待办事项路线图，并且这些任务不会在未来的开发阶段被忽略。
如果某个代码段引发了长时间的讨论，记录所做的决定至关重要。通过添加解释选择和理由的注释，您可以避免将来重复讨论。这些注释可以作为参考，确保未来的开发人员或审查人员理解特定代码段背后的上下文和逻辑。