关于CodeReview的一些思考

来自: 咖啡拿铁(微信号:close_3092860495),作者:Yezhiwei

我们很多人都以为CodeReview不重要,因为其他人写的代码和自己的关系可能不是太大,review的时候也不会上心,但事实上这个想法大错特错。CodeReview和我们的日常开发息息相关,缺少了它,那你的项目就是不完整的了。 本文作者Yezhiwei,我做了一些适当补充。

背景

上图为[产品迭代开发协作流程],其中我们在 Demo 本次迭代之前会对开发人员的代码进行评审,所以今天就聊一下关于CodeReview的一些思考。

Code Review 的主要目标

  • Code Review,也就是我们常说的代码评审。Code Review 主要是在软件开发的过程中,对源代码进行评审,其目的是找出并修正软件开发过程中出现的错误,保证软件质量,同时也能提高开发者自身水平。

  • 代码写不好,可能是对业务不了解,对编程语言不熟悉,也可能对公司代码整体架构不熟悉,我们要找到原因并提出改进的解决方案。

  • 正视 Code Review,不仅仅是过一个流程,而是能从中学习到些什么。

  • 备份,多一两个人熟悉这块业务代码,避免最初的开发者休假等情况发生时,没有人能顶上来。

Code Review 带来哪些好处

从开发者的角度来看

  1. 开发工程师需要按合理的逻辑化分,分模块从原始需求,然后是方案,最后是代码实现的进行讲解。

  2. 这个过程需要的能力:对需求的理解(有助于合理化分功能);表达能力,怎么说才能让评审的同学听懂你传递的信息;逻辑能力,是否有明的逻辑错误;心理压力承受能力,随时会有同学进行提问;

  3. 作为开发者要时刻提醒自己,代码不仅是给机器读,还是要给人看的,所以代码的可读性也要考量,提交代码的信息是否写得非常清楚、合理。想想什么样的代码最想让你骂娘?哈哈... 爱美之心,人皆有之。漂亮的代码,也是我们的追求,它不仅能够完成要求的功能,而且还要整齐,有条理,易于理解。

  4. 分享在这次需求开发过程中运用到的高级技术或一些奇淫巧技。

  5. 代码被 Code Review 后,评审者也相当于参与了这次开发,相当于“备份”,当你休假或正在忙别的需求的时候,这时“备份”就能帮上你的忙了。

  6. 对开发者的一个要求,大家统一代码风格,方便后期的维护。不推荐使用开发工具的自动格式化,手动调整会更好些,也能避免代码冲突。

从评审者的角度来看

审核的粒度要多细?每次评审花多少时间?具体哪些地方需要评审?

  1. 代码格式方面:大家约定俗成,避免公司的代码风格不一致,新同学在这方面不太熟悉,就有可能出问题,但这类问题比较容易解决。

  2. 代码可读性方面:方法不要太长;变量名、方法名要能说明它的用户和类型;不要有嵌套太多层的条件语句或循环语句;循环语句中避免调用远程服务或比较耗时的方法;如果不可避免有一些注释,一定要保证注释准确且与代码完全一致。

  3. 业务边界和逻辑问题:思考一下有没有漏掉任何业务边界和逻辑问题。对现有业务是否有影响等。

  4. 错误处理:有没有对参数验证?远程调用超时或服务不可用时,有没有默认的补救错误?数据库保存出错有哪些影响?

  5. 代码质量和规范:遵循公司的编程规范,如:有重复代码段,就应该提取出来公用;不要在代码里随意设置常数,所有的常数应该在顶部统一定义或有专业的类;哪些变量是私有的、哪些是公有的,等等。

  6. 代码架构:包的组织方式,是否和代码库的风格一致,API 的定义是否 RESTful 等等。

评审者能学到什么?

  1. 深入了解需求及全局的信息架构。

  2. 锻炼了自己的逻辑思维。

  3. 学习开发者的一些奇淫巧技。

  4. 即使没有参与具体的代码开发,但是可以一起与开发者背锅了,哈哈。

从参与者的角度来看

参考者有哪些收获呢?

理论上也应该和评审者没有任何区别。

但是,如果心态和情绪不对的话,可能会变成下面的情况了:

  1. 有了了解需求及全局的信息架构机会。

  2. 学习开发者的一些奇淫巧技的机会。

  3. 可能有了一段带薪刷手机的时间机会,哈哈。

总之,还是看心态,如果在你心中觉得只是一个流程、混个过场,或者带着情绪来做这件事,可能也只能收获这些“机会”,没有达到期望的效果。

Code Review 推荐流程

代码提交

我们现在用的 gitLab 的代码仓库,在每次提交代码的时候,要说明清楚提交的代码到底是什么功能,方便有针对性的代码审核,一般代码提交分四类:

  1. bug 修复,一般需要关联 bug 系统里对应的编号

  2. 代码优化,如重构、移动、拆分方法等

  3. 新功能开发,一般会和需求文档、设计方案关联

  4. 系统迁移,如拆分出更多的项目,分别提交到代码库

发出合并请求,而不是直接合并代码

可以利用 gitflow 中每个分支的生命周期和使用规范,Meger Request 是一次代码提交请求,提交后,其他工程师可以在这次请求中提出修改建议,也可以针对某一些代码的发动进行讨论或是整体的评价。

Code Review 形式

一般来说Code Review的形式有下面两种:

  • 线上

  • 线下


有部分公司都会采用线上,线上的方式更符合开源社区的review的方式,大家通过线上的一些comment和reply来进行交流沟通,这样所有的review其实都有记录可查,但这样会导致一个问题,就是有人比较忙的时候可能就比较敷衍直接就进approve了。


有些公司也会采用线下,线下的方式属于集中式,学习式的review,很多时候这种模式也可以看做一次技术分享,不仅是被review的人的分享,review代码的人也可以将自己过去的经验,分享给其他同学,让大家以后都尽量避免同一个问题或者都用这种方式进行优化,并且集中式的话,大家在一个会议室精力都比较集中,review的质量也较高。但是这种有点不好的是review会占用大量的时间,如果平时本来开会就多,开发时间就少,再来几次review,那不想996也难呀。

有哪些收获?

  • 提高了代码质量,知道自己的代码会被别人评审之后会写得比较认真。

  • bug 数量减少,经过各个环节的评审,目的就是避免代码返工和 bug 生产,有的是带薪写 bug 哈哈。。

  • 团队成员对整个项目的熟悉程度会比较均衡,代码不会只有当初的开发者了解,Code Review 后所有的参与都能修改 bug,增加新功能。

  • 避免人员单点风险。

  • 每个成员都可以审核别人的代码,多沟通、营造团队的技术氛围。

推荐↓↓↓
程序员的那点事
上一篇:大龄程序员深谈实录,那些你关心的话题都聊到了 下一篇:从一次问题讨论聊聊我对阅读源码的思考