腾讯如何有效地进行代码 Review
共 3702字，需浏览 8分钟
· 2021-09-12
AI全套：Python3+TensorFlow打造人脸识别智能小程序
最新人工智能资料-Google工程师亲授 Tensorflow－入门到进阶
黑马头条项目 - Java Springboot2.0（视频、资料、代码和讲义）14天完整版
需要注意的事项
在代码 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>(<scope>): <subject><BLANK LINE><body><BLANK LINE><footer>
大体分三行：
【标题行】必填, 描述主要修改类型和内容。
【主题内容】描述为什么修改, 做了什么样的修改, 以及这么做的思路等等。
【页脚注释】放 Breaking Changes 或 Closed Issues
其中 type 是 Commit 的类型，可以有以下取值：
feat：新特性
fix：修改 bug
refactor：代码重构
docs：文档更新
style：代码格式修改
test：测试用例修改
chore：其他修改, 比如构建流程, 依赖管理
其中 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 的目的包括：
发现那些明显的疏忽，如代码 debug 过程中留下的不必要的痕迹，比如 fmt.Println(…)，不小心注释掉的代码。
之前被 Reviewer 多次提出过的问题。
Commits 是否正常，在多人协作的情况下 MR 中否带入了不相关的 Commit。
Commit Message 是否合适。
Self-Review 是一个非常快速的过程，从我个人的经验，一般 1-2 分钟即可完成，所以推荐大家养成 Self-Review 的习惯。
Review 些什么
经常会有 Reviewer 拿到 MR 不知道该 Review 些什么，其实无论你参与对应项目的深入如何，都可以对代码进行 Review，也鼓励不同人从不同的深度、角度去帮助 Review。代码 Review 没有固定的形式，它更像是一门艺术，唯一的提高办法就是实际参与进去。
Review 的时候可以从以下几个方面入手：
常规的 Review
代码 Review 一般都会从代码风格、变量命名、语法统一处入手，当然这些应该更多的借助于 CI 等自动化手段来保证，但是在相关流程还不是很完善的前提下还是有必要进行关注。
此外代码可读性、代码健壮性、代码可扩展性都是 Review 时关注的点。每一个关注的点都依赖于 Reviewer 的实际经验，这里只简单举几个例子：
代码可读性
代码是写给人看的，因为没有不需要维护的代码，无论是 Author 自己后续维护代码，还是他人接手代码，能快速地理解代码逻辑是非常必要的。
代码 Review 的时候可以关注以下几点：
变量、方法的命名是否合适，是否真实反映了他们的目的，这方面网上可以找到不少的资料说明。
实现的逻辑是否已有现成的库可以替代。如果有成熟的库可以使用，尽量不要自己去实现，因为可能会引入不必要的 bug。从我个人的角度，简洁（大白话就是代码少）是可读性一个很重要的指标。
关于注释。代码注释不求多，而在于有效，以前也经历过代码注释要求至少达到 30% 以上的年代，现在看来过多依赖注释其实是对代码质量的不自信，好的代码应该尽量做到自解释。在实际过程中偶尔能看到代码逻辑实际已经清晰明了，但是用语句不怎么通的英文注释了一通，最后反而是看懂了代码才能理解注释到底说了啥。因此 Review 的时候，不必要的注释可以建议去掉。
不好理解的地方要有恰当的注释。代码中如果有特殊处理、特殊的常量、或者不符合一般用法的逻辑需要特别注释说明一下。
代码的组织。良好的代码应该有较好的封装以及层级，使得代码看起来清晰明了，比如 DAO 层、Service 层。
代码健壮性
代码的改动是否会影响其他功能。
用户参数是否做和细致的校验。
有没有 Panic 的可能（针对 Go 的说法）。
是否会破坏 API 的兼容性。
可扩展性
当前的实现方式是否能兼容以后类似的扩展需求。比如在新增接口、API 或者调整参数以解决某一问题上，可以考虑是否后续会有其他类似情况发生。举几个例子：
假设我们需要定义一个 API 接口去获取一个用户的某些信息，例如联系方式等，我们定义的 API 就不能只返回这些信息，而是应该把用户相关的信息都返回。
假设我要定义一个参数，虽然当前定义成单个元素即可满足，例如 string, int，但是以后是否会涉及到多个元素的场景，是否定义成 []stirng, []int 是更优的。
这里只是举了有限的一些例子，在实际 Review 过程中，Reviewer 可以根据自身的经验从各个角度提出优化的意见。一般需要重点看看：
你看不懂或疑惑的地方。
打破你常规的地方。
复杂的地方。
关于 Comment
代码 Review 很大程度上就是给代码挑毛病，而且一般预期挑的越多越好，但代码是 Author 写的，很多情况下或多或少会对 Author 造成不适。所以在 Comment 的时候需要尽量注意措辞，尤其是一些主观的东西，一般以建议的方式给出。当然对于原则性的问题，是要坚守质量标准的，甚至可以直接 Deny 掉 MR。
另外，参与者也不要吝啬你的溢美之词，无论是 Author 还是 Reviewer，在 Review 中发现了好的地方或好的建议，请给予对方以肯定和赞美，这样有助于 Review 有效的进行。
看完本文有收获？请转发分享给更多人
往期资源：