Code Review
代码评审，简称 CR
为什么要进行 CR
CR 的好处众所周知，这里不详细述说
- 提升代码质量
- 减少Bug，降低系统风险
- 相互讨论学习，提高团队能力
为什么很多公司推动不了 CR
- 项目大且乱，一时半会看不完
- 业务需求 VS 代码评审
有些项目很大很乱，说不定一次 CR 会议，两个钟下来都 CR 不完，或者都还没理出头绪就会议结束了。
大部分公司都是产品业务驱动型，少数才是技术驱动型公司，所以一般公司内部都是以业务为主，很难有时间来 CR。
争取 CR 时间
当业务需求和代码评审冲突时，跟产品争取时间来进行 CR
- 项目急不急，能延期上线？
- 部分功能有没有用，能砍掉？
- ...
争取失败才是正常
失败是平常心，大部分时候，业务需求很难让步，但有些也是有机会，看你自己怎么争取。
既然失败了，该怎么办呢？
粒化 CR
个人觉得 CR 可以拆分不通阶段来完成不同的职能，以达到粒化的效果。
- 第一阶段：代码是否规范（ESLint、命名、注释）
- 第二阶段：目录结构是否合理
- 第三阶段：文件、函数是否过长
- 第四阶段：项目内小架构（项目骨架代码、可重用逻辑等）
- 第五阶段：业务逻辑优化
- 第六阶段：待定
因为还没试过粒化 CR，不知道粒化得是否合理，后面在公司内部推行后再来看下效果，再回来调整粒化的阶段内容，以达到较优。
每个阶段都在什么时候进行 CR
如果有足够多的时间来CR，肯定在上线前进行所有阶段 CR 并优化完。
时间不够的话，粒化CR就派上用场了，按照时间安排进行不同的阶段CR。
上线前
前两个阶段不影响逻辑，我觉得可以在开发期末来 CR，亦或者在测试期修 Bug 来 CR 也行。
如果这都完成不了，那只能是你们自己的问题。
ps： 上线之前至少需要完成第一阶段的 CR，尽量连第二阶段也完成
上线后
每隔一周进行一个阶段的CR，如果项目太多复杂，可以在阶段内分模块进行CR。
这时候也别又说没时间，不然又回到最开始的问题了。解决办法总是想出来的，不是坐等送上门的。
后面这些阶段目前还没实践过，不打包票，等尝试过后再回来填充。
话外题
第一、第二阶段是否有需要保留
诚然，有些人认为前两个阶段应该算作个人基本功，不应该拿来当作CR，但我想说的是，这可能是大厂或大牛们的个人基本功。
其实大部分中小型企业、创业型公司，很多人前两个阶段都很难做到，所以才把这两个阶段列进来，如果你的团队已经优秀到每个人的前两个阶段都扎实，那可以直接忽略掉，直接进入第三阶段。
如果觉得我 CR 粒化的不够完善，不够合理，欢迎指出，大家一起学习，毕竟这也是我的一点思考，还没能确定这样粒化是否是正确的。
富有同理心
CR 推行者需要提前强调 review 和被 review 的人心态要放好，要有同理心，该尊重的要尊重，该虚心接收的虚心接受。
凛冬将至
最近各种裁员信息层出不穷，建议大伙们放好心态，不要裸辞，不要裸辞，不要裸辞，重要的事说三遍，安心学习准备，以待春天来临。
参考地址
https://coolshell.cn/articles/1302.html
//www.greatytc.com/p/6b1e7a6e83d3
文章可随意转载，请保留此 原文链接
