如何在团队中推动Code Review

2,602 阅读3分钟

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 的人心态要放好,要有同理心,该尊重的要尊重,该虚心接收的虚心接受。

凛冬将至

最近各种裁员信息层出不穷,建议大伙们放好心态,不要裸辞,不要裸辞,不要裸辞,重要的事说三遍,安心学习准备,以待春天来临。

参考地址

coolshell.cn/articles/13…
www.jianshu.com/p/6b1e7a6e8…

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