如何为团队建立更好的 Code Review 原则与规范？

在如何做好 Code Review? 如何写出更快通过 Code Review 的程式码? 一文当中我们从个人的角度出发，来聊 Code Review，包含谈了帮别人审查程式码，或者自己的程式码被审查，分别有哪些要注意的要点。

在这一篇，我们将进一步讨论，从团队的角度如何看 Code Review。对于想要迈向资深的人来说，从团队的视角出发看事情，是非常重要的。资深工程师不仅要做 Code Review，还需要协助团队建立、优化 Code Review 的规范与流程，以及协助塑造良好的 Code Review 文化。

Code Review 流程建立

如果你所在的团队，还没有完整的 Code Review 流程，推荐你可以主动跳出来，协助建立流程。

以下是常见的工程团队 Code Review 流程：

首先，当写完程式码后，把程式码发到远端分支，并且透过 CI 完成自动化检测 (下一段会详谈)
自动化检测有通过的话，即可对要合并的分支发起 Code Review。现代的程式码库工具，例如 GitHub 与 GitLab，都有相关的差异比较 (diff)，让人一眼能看出哪些程式码被改动
接着，邀请相关人员给 Code Review (或是目前许多程式码库工具，会自动扫过提交的程式码，并寻找相关文件中其他程式码的提交者，并自动分派给这些过去写过相关程式码的人，让他们当负责审查的人)
相关人员针对 PR 给予回馈，而 PR 作者针对回馈调整程式码。这是个来回的过程 (但不宜拖太长)，直到改到相关人员觉得没问题后，留下 LGTM (Looks Good To Me) 后，通过 Code Review，接着可以将程式码合并

CI 当中要检测什么

由于工程师的时间宝贵，在 Code Review 开始之前，有些该确保的基本事项，可以透过自动化的工具，整合在 CI 的流程中，这样就不用浪费其他工程师的宝贵时间，来把关某些可以直接被自动化工具把关的内容。

具体来说，目前业界许多团队会在 CI 上放入以下节点，推荐可以导入相关：

型别校验 (type check)：确保没有错误的型别
静态检查：最常见的是 linting，确保有符合程式码库设定的 linting 规范。另外也包含风格 (style) 的检查。Code Review 本身不该着重在风格检查，这应该交给静态检查工具处理
程式码复杂度 (code complexity)：确保程式码不会过度复杂，目前社群中有 SonarQube 等开源工具，可以协助检测
测试：多数团队会在这部分加上覆盖率的标准，假如没有达到某个覆盖率，就不会通过
效能检测：业界目前也有许多效能检测工具，可以串在 CI 上面。以网页前端来说，目前在 CI 上面可以串 Google 的 Lighthouse，有些团队会设定，如果 PR 导致 Lighthouse 跑分下降，则会不通过
建构：确保程式码能顺利建构

推荐团队要有的 Code Review 原则与规范

在通过 CI 上设置的检测后，接着进到实际的 Code Review，推荐团队可以有以下原则：

尽早完成：

因为 Code Review 拖延意味着功能交付会拖延。理想上可以在一天内完成 Code Review，完成是指从 PR 提交，到多轮回馈，到最终通过并且合并程式码。从团队的角度，要确保工程师有办法拨出足够的时间。如果工程师都太忙没办法抽出时间来审查，那工程经理需要协助调整工作负担与分配。

清楚的 Commit 讯息

如果是使用 Git 做版本控制，要发 PR 前，工程师都需要先把自己写的程式码 commit 起来。而 commit 的讯息的规范做得好，对于要帮忙审查的人，甚至是对于未来要维护的人会更轻松，因为可以在茫茫的 commit 讯息中，一眼看出该去哪个 commit 找修改纪录。

在业界常见的 Commit 讯息规范，会是在每个讯息的最前面加上前缀，让人一眼看出是什么类型的 Commit 讯息，同时讯息尽量保持一行，精简描述该次改动作了什么。

在这个 Conventional Commit Messages 开源专案，有更详细的解说，包含

feat 代表这个 commit 是跟新功能有关
fix 代表这是一个修 bug 的 commit
refactor 代表这是跟重构有关的 commit
style 代表风格调整相关的 commit
test 代表是跟测试相关的 commit
chore 如果找不到某个分类，可以用这个

PR 要加上 Test Plan

在 PR 当中，推荐除了写改动了什么，也要加上 Test Plan (测试计划)，让帮忙审查的人，一来可以更具体知道改动之处，二来如果测试计划想的不够周全，也可以在 Code Review 时给回馈来调整。下面附上前 Meta 工程师 Dan Abramov 在开源专案发 PR 时附上的 Test Plan，让大家参考。

PR 要加上 demo

如果是前端类别的改动，包含 Web 与 Mobile (iOS 与 Android)，推荐要有加上 demo 的规范。最常见的方式，是加上荧幕录影，让人可以一眼看出改动了什么，这对于帮忙审查的人快速进入状况很有帮助。下面附上前 Meta 工程师 Dan Abramov 在开源专案发 PR 时附上的荧幕录影 demo，让大家参考。