现实是 Code Review 只会拖慢项目进度，真正的隐患往往是 Review 之后合并进了主分支，而很久之后才被发现

Code review 内容有好几种：
1. 看拼写、规范
比如 typo （还不是那种自动拼写检查能查出来的那种），使用了错误的变量，缩进不合格，注释不详细等
2. 看业务
这个真的只有看需求和经验了。明明这个操作要把购物车里所有的东西打折，你却把收藏夹打折
3. 看代码实现
“再开个线程，不要阻塞 UI ”
4. 排雷
“下个月我离职，所以这段代码在 3 个月后会删库”

review 配合单测很重要，review 实现的时候，看的基本是大概的框架和流程，功能逻辑的正确性交给单测保障，流程没大问题直接去看单测方案是否全面，所以我个人在单测的要求和 review 单测的精力往往投入更多

为啥要搞成 2 人批准？个人觉得 1 人足够了

Code review 是为了保证你的 code 不会违反一些原则（比如 single source of truth, don't repeat yourself ）。这样以后发现问题更好处理。而不是保证没有 bug。

真正的隐患往往是 Review 之后合并进了主分支，而很久之后才被发现

幸存者偏差

git lab code review 的时候只能看到修改与新增的东西，没有看到完整代码和业务逻辑也很难明白对方是在做什么，而且大家都这么忙，感觉只能看看风格和明显的逻辑错误这种东西了吧；但是 review 一下确实也能学习一下对象的思路啥的

@weixiangzhe 羡慕你们能学习对象的思路的

@ZiLong 打错字啦 不搞🐔的

@weixiangzhe 不搞🐔的,我们只是 do chicken right!