How to Achieve a Smoother Code Review Process?

如何达成更为流畅的代码审核？

#Communication

前言

开发至今从未特别了解如何有效执行代码审核，大家默认会写代码就能审核他人代码，但我认为这是一门额外的学问，促使我写下这篇文章去了解如何进行代码审核。随着时间推移，我会不断编辑这篇文章，逐步解决我在代码审核中遇到的问题……

要对审核的代码理解多深？
审核代码是实际的产出吗？
主持一个成功的代码审核要怎么做？

受审者

准备好代码审核所需的一切信息

代码用于实践产品行为，而在审核如何达成目标的手段（How）之前应当充分了解为什么（Why）要这么做，提供完整的背景信息可以帮助审核者更好地理解代码目的。要求他人审核代码之前提供必要的上下文信息，尽量帮助审核者更有效率地进入审核的心态与环境当中：

规格书
设计稿件
测试环境、相关技术文件链接

更进阶可以补充的信息则像是：

如何切入这次代码改动（某文件、某片段或文档）
自己是如何测试并确保代码正常运作的（通过自动化测试或至少用文字简单描述期望行为）

有时候调整 UI 相关的代码时，我会一边根据需求改动，一边开 excalidraw🔗 这类白板工具并截图自己测试确保没问题的过程，人们总是对图像的理解更快，负担更轻。

尽可能缩小审核的规模

一个庞大的审核，不管是审核者还是被审核者都会感到无比的压力，且专注度会直线下降。

单纯注意力是每个人都有限的资源，当审核的规模扩大就意味着审核者需要腾出更多不被打扰的时间专心审核，这点并不是每个人都有办法做到，所以我们应该尽可能缩小审核的规模，瞄准更迅捷的迭代，并在每次小改动中更容易找出问题。

不过这比较偏向团队的默契来决定如何管理，举例像不同的版本管理策略也会影响迭代速度：完整介绍 Git 分支策略 feat. Git Flow, GitHub Flow, GitLab Flow, TBD，我自己更偏好快速且频繁的迭代，不过也还是要看团队的习惯与产品性质来决定。

审核者

为反馈提供分级制度

在审核时应当留意我们的“目标”是达成共识并尽快结束审核，或许可以额外为反馈分级会是个好方法，例如标示：Nit(nitpick): 钻牛角尖的小问题，可以参考就好。

为了在完美代码与时间成本间达成平衡，我认为每次审核者都应该给出明确的界线告知被审核者“最少哪些是应该被修正才会通过审核”，真正重要的问题解决后再去看彼此有没有多余的时间去研究细微的问题。

尽快审核给予反馈

当审核的时间拖得越长，需要审核通过的压力就会累积在受审者身上，相较于追求代码品质更多时候意味着放弃重构改进代码，而只是专注在尽可能审核通过就好。

审核者可以加快反馈速度来弥补这一问题，或是在预期没办法在短时间内完成审核时提前告知被审核者，这样可以让被审核者有心理准备去处理其他事情或找其他审核者。

风格标准

有的事情并没有绝对的好坏，这样的问题时常会让审核者与被审核者产生争执但永远不会有明确的结果，例如语法风格、命名规则风格……等，可以在团队中取得共识，并在之后就算有反对也要同意完全遵循规范（Disagree and commit🔗）以将时间花费在真正重要的事情上。可以搭配自动化的 Linter 工具来审核这类风格问题，建立硬性规定。

总结

审核代码是最直接可以发掘并改善问题的环节，主持得当的代码审核能够补足团队成员间的知识盲区，进而提升整体代码水平。

确保代码的质量，从而确保了产品的品质
减少未来的技术债务，使维护成本更低
提供开发人员之间的知识共享，从而提高工作效率并提高公车指数

全站搜寻