Code Review在一些公司是必要流程,在一些公司是可选流程,在另一些公司则只是名词。在工作了N年之后,分别经历过这几种类型的公司。

Code Review的好处

在过往的工作中,自己能够体会到的Code Review的作用大体有,

  • 帮助统一项目编码规范
  • 及时排查有误的代码设计与实现,提升整体代码质量
  • 便于培训新人,加强组内互相学习,促进成员之间互相了解对方工作内容

为什么Code Review难以推广

Code Review的好处很多人都知道,参与过其中的更能明白。但工作过的同学们更应该了解,实际工作中Code Review是有多么稀缺。从个人了解到的信息来看,国外一线公司是有完备的Code Review流程的,但国内公司,不论是一线大厂还是创业公司,不论是互联网还是游戏还是传统企业,在这方面统统有所欠缺,以至于哪个公司有Code Review都是可以拿出来夸赞的。

为什么会出现这种情况呢?

首先,这是一个意识问题。国内企业少有技术主导或技术核心型公司,非技术人员很难理解这种没有直接产出的工作的意义,因此在初始的工作流程上就不会考虑增加Code Review这一流程。

其次,这是一个文化问题。国内盛行加班文化,个人认为存在加班文化的公司很难会去做Code Review这件事情。加班的目的是为了产出,或者是为了让领导看到产出,Code Review这种没有直接产出的工作很难适应这样的文化。

再次,这是一个绩效问题。Code Review不能帮助提升绩效,在周报月报上很难将此列上。有投入,无回报的事情是难以持久的。虽说Code Review能够带来多少多少好处,但具备主动学习能力的人有的是方法学到东西。

从次,这是一个效用问题。大部分代码都是业务代码,业务代码的一个现实困境就是多变。多变的需求导致代码变更频繁。很多时候做了Review,但很快整个功能就变了或被砍了,导致Review变得没有意义。

最后,这是一个成本问题。Code Review一来需要投入时间,二来需要有人来参与。很多时候某一个功能模块只有一个人负责,其它同事最多只能从代码风格上提出意见。在Review之前先去了解对应的功能需求就需要投入时间与精力,在各自都有事情去忙的时候,很难持续这么去做。这样就会导致Code Review的作用不那么明显,久而久之也就不再继续了。

另外,还有一个时间问题。这个要看项目的开发周期,以现在所处的项目举例,每周一个版本,周五出需求,周四打版本,实际可用于开发的时间只有四天。四天时间里需要理解需求、编码实现、自测、解决bug,以及再处理部分临时需求,导致完全没有精力去好好做Code Review。

推动Code Review的时机

虽然Code Review很难推广开来,不过在恰当的时机还是可以尝试去推广一下。毕竟如果处于一个学习型组织对自己的提升也是有益的,能做多少就是多少吧。

最好的时机,新人加入的时候。新人的代码通常各种问题,因此让其进行Code Review不会遇到太大阻力。如果处理得好,可以借机推广。

次好的时机,代码频繁出问题的时候。如果一段时间内整体代码质量下降,那么可以尝试去推进这件事情。毕竟Code Review对提升代码质量是有帮助的,这个时候的投入容易说服他人。

Code Review的注意事项

Code Review的第一要则,一切以代码说话,避免人身攻击。

Code Review的方式选择

Code Review有两种方式:提交前Review、提交后Review。就个人经验来看,如果要做Code Review,就选择提交前Review。

Code Review相关工具选择

直接选用常用的Code Review工具,

任何一款,真正去用了,都是能发挥作用的。

总结

Code Review对程序开发来说很重要,不过现实中很多人觉得其并非不可或缺,于是往往被省略。但实际上它是程序开发的一个必要基础设施,作为一个“专业”人士,要顺势而为推进参与其中。

在没有Code Review的技术组织中工作,对个人成长是不利的。可以分析分析导致没有Code Review的原因是什么,再来看看是否有必要继续待下去。