一个好的code review，基础的是能检查bug，更好的是能从架构和设计上进行检查和思考
Aim of Code Review
- 预防bug,保证代码质量——首要目的
- 完善产品代码设计，架构设计
- 形成团队规范
- 增强成员之间的沟通
- 代码技能提升
不找不做Code Review的借口
- 迫于业务的压力，PM又来催进度了，能快点就快点，实现功能就好；
- 反正这块业务由我负责，我能看懂就行；
- 交给别人code review，感觉有点浪费别人的时间；
- 当然还有很有很多理由...
这些理由都没有问题，或许工作中是会遇到这样那样的问题，让我们忽略了code review。但是，这都不是让我们放弃code review，code review带来的利永远要大于弊。
How to Code review
PR时都应该检查些什么？这里准备了两个列表：required checklist & recommended checklist
required checklist所列内容建议RD先自行代码diff，再提PR给reviewer.
Required checklist
满足下列条件之一，不能合并PR:
- 有明显的bug, common mistakes例如：
-
-
缺少error handle
- 例如异步缺少try catch
-
-
-
缺少完整性
- promise不catch, 必要场景下只写if 没有else
-
缺少判空
- a.b.c.d （a = null）
-
-
有潜在的bug
- 例如：corner cases ，业务逻辑潜在bug等
-
未删除console.log
-
随意设常数
- 例如 if (a === 10 || a === 40) {...}
-
复杂逻辑缺少解释性的注释
-
冗余代码未删除
- 不允许添加未使用的变量、模块、依赖等
除此之外，最好检查下这些：
Recommended checklist
-
变量名命名是否恰当，是否语义化
-
a, ab, t1, t2, t3... NG
-
关于代码变量命名：
一段代码的逼格，一半以上是靠变量命名体现的。这个是实话，同一个概念，你是用的语言是否正规，单复数是否分清，形容词副词是否分清，是否合理使用倒装，确实很能体现一个程序员的逼格。往大的意义上说，一个项目中的变量名，是否规范，是否收敛（同义词收敛为一个并且有规范），也是项目质量的体现。
-
-
是否可能导致性能低下
-
随意添加并不真正必要参数
-
不使用已有的功能而去自行写一个
-
是否存在面条式代码
-
引入新的依赖是否必要
-
代码可读性
- 例如 嵌套太多、一个函数返回不一致
-
代码的耦合度
- 高内聚，低耦合
-
代码复用性
-
代码扩展性
-
commit message是否规范？
-
方案设计是否恰当
-
文件组织是否合理
- helper? utils? components ...
-
如果是重构，有文件迁移，第一条commit需要原封不动的将代码迁移，不然不会有修改记录 这是个很好的实践 👍
切记：改动较多，提前PR
有种建议是：一次code review 不要超过400行，超过400行，很难发现bug
