腾讯如何有效地进行代码 Review ？

需要注意的事项

在代码 Review 上，Author 需要意识到：Reviewer 的时间是昂贵的。因此在正式邀请 Reviewer 发起代码 Review 前，Author 有几项需要注意的点，这些都能提高代码 Review 的效率，节省 Reviewer 的时间。

Commit Message

之前翻看了不少现存的项目代码，看到不少的 Commit Message 写得比较简单，例如一连串的 "update", "fix"，从这些 Commit Message 中完全看不出做了什么改动，想想如果之后想要定位之前的某个改动，该从哪里下手。

目前 Commit Message 规范比较常见的有 Angular 团队的规范，并由此衍生出了 Conventional Commits Specification，可以参照此 Specification 约定 Commit Message 格式规范。

(): 

大体分三行：

其中 type 是 Commit 的类型，可以有以下取值：

其中 scope 表示的是 Commit 影响的范围，比如 ui，utils，build 等，是一个可选内容。

其中 subject 是 Commit 的概述，body 是 Commit 的具体内容。

例如：

fix: correct minor typos in codesee the issue for details on typos fixed.Refs #133

Commit Message 可以在 git 中配置模板，这样可以在 vim 中展示出模板，另外可有工具帮助我们生成和约束 Commit Message，例如 commitizen/cz-cli，这里不再具体说明。

Self-Review

我们一般代码 Review 都是找他人来进行 Review，其实负责任的 Author 在邀请他人来代码 Review 前也需要自己简单 Review 一遍，即 Self-Review。

Self-Review 的目的包括：

Self-Review 是一个非常快速的过程，从我个人的经验，一般 1-2 分钟即可完成，所以推荐大家养成 Self-Review 的习惯。

Review 些什么

经常会有 Reviewer 拿到 MR 不知道该 Review 些什么，其实无论你参与对应项目的深入如何，都可以对代码进行 Review，也鼓励不同人从不同的深度、角度去帮助 Review。代码 Review 没有固定的形式，它更像是一门艺术，唯一的提高办法就是实际参与进去。

Review 的时候可以从以下几个方面入手：

常规的 Review

代码 Review 一般都会从代码风格、变量命名、语法统一处入手，当然这些应该更多的借助于 CI 等自动化手段来保证，但是在相关流程还不是很完善的前提下还是有必要进行关注。

此外代码可读性、代码健壮性、代码可扩展性都是 Review 时关注的点。每一个关注的点都依赖于 Reviewer 的实际经验，这里只简单举几个例子：

代码可读性

代码是写给人看的，因为没有不需要维护的代码，无论是 Author 自己后续维护代码，还是他人接手代码，能快速地理解代码逻辑是非常必要的。

代码 Review 的时候可以关注以下几点：

代码健壮性

可扩展性

当前的实现方式是否能兼容以后类似的扩展需求。比如在新增接口、API 或者调整参数以解决某一问题上，可以考虑是否后续会有其他类似情况发生。举几个例子：

这里只是举了有限的一些例子，在实际 Review 过程中，Reviewer 可以根据自身的经验从各个角度提出优化的意见。一般需要重点看看：

关于 Comment

代码 Review 很大程度上就是给代码挑毛病，而且一般预期挑的越多越好，但代码是 Author 写的，很多情况下或多或少会对 Author 造成不适。所以在 Comment 的时候需要尽量注意措辞，尤其是一些主观的东西，一般以建议的方式给出。当然对于原则性的问题，是要坚守质量标准的，甚至可以直接 Deny 掉 MR。

另外，参与者也不要吝啬你的溢美之词，无论是 Author 还是 Reviewer，在 Review 中发现了好的地方或好的建议，请给予对方以肯定和赞美，这样有助于 Review 有效的进行。

入群须知

为了构建高质量的技术交流社群

减少低质量内容的产出，建议入群前先阅读本须知

了解本社群所涉及的内容主题与相关群规

创建几个氛围良好的程序员技术交流群

扫码加群，先到先到