如何在团队中推动Code Review

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
https://www.jianshu.com/p/6b1e7a6e83d3

文章可随意转载，请保留此 原文链接