背景
代码评审(CodeReview,简称CR)作为很多研发团队的标准化部分被广泛使用。听到有很多工程师在代码评审时有这样一些疑问:
1、代码评审要达到哪些目标?
2、哪些方面是我应该评审的?哪些不是?
3、别人有没有认真的评审我的代码?如何让别人评审代码更容易?
今天咱们一起使用3W方法来透过问题看本质。
What
先来看看两个看似不相关的概念:什么是CI和CD。
Continuous Integration:持续集成,简称CI,是软件开发周期的一种实践,把代码仓库(Gitlab或者Github)、构建工具(如Jenkins)和测试工具(SonarQube)集成在一起,频繁的将代码合并到主干然后自动进行构建和测试。简单来说就是代码编写到提交到主干的过程。
Continuous Delivery:持续交付,简称CD,是在CI的基础进行了扩展,在CI环节完成了软件构建和测试工作并形成了新的版本,那么接下来就要进行交付,而这里的交付并不是交付到生产环境,而是类生产环境(STAGING),我们可以理解为灰度环境或者预发环境,进而接受部分真实流量的测试。简单来说就是主干上的代码到生产发布中间的自动化检查部分。
CD还有另外一个名字:Continuous Deployment:持续部署,它是在持续交付的基础上打通最后一公里的工作,就是把手动部署到生产环境的方式升级为自动部署。谷歌的一些开源代码就是采用这种方式部署的,第一次自己的代码被采纳的时候,对他们的自动化能力还是挺震撼的。
咱们先来说CI的意义价值(以下为我同事的总结,内容是借的):
1> “快速失败”,在对产品进行自动化验证,并快速响应
2>减少风险,降低成本
3>将重复性的手工流程自动化,让工程师更加专注于代码
4>提高项目的能见度,方便团队成员了解项目的进度和成熟度
5>增强开发人员对软件产品的信心,帮助建立更好的工程师文化
CodeReview是CI的一个环节。自然要以CI的意义价值作为目标。控制的方法是设置一个卡点,只有评审通过的代码才能合并到主干还是分支上(取决于使用的是基于主干开发还是分支开发)。
Why
CI的原则是尽量使用自动化,CodeReview则是强烈需要人工介入的部分。为什么这么做呢?
1>避免设计理解偏差
经常有这种体会:自己作为设计者觉得已经将方案给开发人员传达的很明白了。并且开发人员自己也说明白了。但是让开发人员来复述,却多少会发现和自己想的不同。
下面密密麻麻的都是我为了一个总代码不算单测不超过500行的小优化做的,从整体到部分,自己觉得用活动图几乎覆盖了每一行代码:
连最简单的接口,源码几乎可以照抄旁边的的Service接口,还有下面的活动图:
也很有可能最终看到代码和自己想的不一致。而且实际中概率很高。完美的诠释了帕累托图的本意:二八原则。80%的都不一致。
2>知识传播
发现不一致,code review中间沟通,探讨的过程是相互学习的过程。我非常喜欢这一过程。但是鉴于每到code review,我的表情都非常凝重。好吧,看起来不只是凝重,所以估计被我review的同学看不出来我是欢喜的。
、
3>检查逻辑正确性
一旦线上出了问题,后悔、不甘……付出的代价和对应的精力不只是十几倍的差别。线上出现小问题,我一般反而特别急于下班,能早回就早回了。不是逃避,而是在哪里脑子都在思考、反思。不如回家躺床上思考精力更集中一些。
How
1>找对人
结对编程这个名词流行好多年了。但是现代对代码质量要求、线上稳定性要求都很高的这几年,优势才慢慢体现出来。因为结对编程,这两个人对代码逻辑都是了解的。找个不了解的人做code review,要不就发现不了问题。发现了也多半是技术性或者风格性的问题。而真正重要的逻辑问题往往发现不了。
这里提示一点哈,不知道会不会有同学对结对编程还停留在一个人写代码,另外一个人要在旁边盯着这个层面。设计、代码都是双方一起交流沟通过,评审过的就可以啦!
2>用对法
code review的同学一定要有checklist,避免遗漏重要检查点。下面是我整理的checklist:
注意文件是否有因为测试而进行的注释
注意单测覆盖率是否增加或者持平
是否缺少必要的注释
使用velocity模板:vm、xml和properties三者需要同时修改
一次代码提交不允许提交多个功能,单个功能可拆分成多个子功能分别提交
修改范围必须是本次功能涉及的范围,其他不允许修改,哪怕删除一个空行
除非新类或者类的所有功能全部进行了修改,否则不允许整个类全局format
所有的代码修改必须有单测,如果原来没有覆盖到这个分支或者对修改没有相应的断言必须补充,哪怕修改的是日志打印。日志打印可通过将打印日志加到单测类注释中手动对比实现,注释必须提交
façade的POJO必须序列化
3>讲原则
上面checklist中很多内容比如先和其他人约定好。比如:一次代码提交不允许提交多个功能,单个功能可拆分成多个子功能分别提交。约定好的就只能照做。否则别人写完再提出来,code review和被review的同学都不舒服。情绪控制不好,反而容易写出糟糕的代码或者犯错。
往期推荐