Code Review

前言


其实从我毕业到前不久,整个项目流程很少有code review,所以今天来好好讲讲code review是什么东西。

很多东西存在,它有存在的原因

比如说第一家公司的时候,是产品带团队,关注的是结果,关注的是运营数据,至于项目质量,其实产品在这方面经验是很少的。还有另外一个原因是业务太忙了,需求几天搞完,业务都搞不完,哪有时间做这些技术审核。

code review有没有必要?

Code Review_第1张图片

code review意义在哪里


以前没有这个步骤的时候,项目流程也能跑呀对吧,感觉可有可无。其实它是属于项目质量的一环,我们以前经常会出现一些低级bug导致线上问题,或者说写了一堆只有自己能读懂的代码,其他人根本就接手不了。(提高下自己不可替代性是吧,哈哈)

code review是通过reviewer来进行审核别人提交的代码,通过一定的规则,判断代码是否有问题,然后跟开发者进行沟通解决。

code review的时间点


开发中:在coding阶段及时发现问题,这样可以减少后续复工的情况,比如说都测试完了才发现问题,你改完问题,人家还要再测试一遍,qa一jio就过去。

测试中:我比较习惯这个时候去review的,因为一开始写业务代码的时候,我很烦别人一直 打断我的思路,我想一把梭哈,然后后面慢慢修。如果你去理发店剪头发,你就有体会,tony老师会先把边边角角修了,然后才用剪刀进行精修。

我们就要根据实际情况进行择时进行code review

review内容


review的目的是什么,决定它的动作是什么~

review是为了业务上实现功能,技术上可读性、可维护性、可扩展性,那么对于提交代码也需要关注这些,而不是让代码变成一个屎山,然后大家不断累积上去,最后无法维护,进行重构。

逻辑上


这个是最基本的要求,如果连逻辑都无法实现功能,那还玩什么自行车‍♀️哈哈。
首先我们看下需求文档,自己上手去系统熟悉下业务,然后看下设计文档,设计文档里头就会有数据库设计,接口罗列,物理架构图,逻辑架构图,还有一些核心的交互对吧,然后再开始看逻辑是不是对的上。

技术上


可读性

这个很好理解,就是别人一个小白通过你的方法名、注释就能看出你写的是啥玩意,而不是一顿分析,一顿操作,然后还有点闷逼。

可读性有什么表现呢?

  1. 代码格式。整体代码风格保持一致,比如说我们吃水果是先洗下,再削皮,再吃。忽然哪天是吃一半,再削皮,整个人都不好了。代码风格的一致性,可以让阅读者比较好的阅读环境
  2. 注释。我之前也不喜欢写注释,一把梭哈,人或者代码能跑就行。但是当你去阅读别人这样的代码的时候,就会很恼火。其实写注释有几个目的:一个是把我们的思路写出来,敲代码的时间不是很多,思考这个思路的时间应该会更多写,所以把思路写下来会让我们整个作业清晰些。另一个目的是一个项目有时不仅只有一个维护者,多人开发或者以后别人接收你的工作,要让别人看得懂代码
  3. 方法里头逻辑简洁。有时习惯性把所有逻辑都怼到一个方法里头,可能你看完上面的逻辑,看下面代码的时候,上面的逻辑又忘记了。所以方法要尽可能的简洁明了,这样小白可以通过方法名,或者方法上的备注,一眼看出这个方法是干嘛用的
  4. 提交记录清晰。就是我们在提交到远程代码的时候,这个备注是清晰的,我们看下开源代码,可以通过提交记录清晰的知道我这次修改的是啥内容。当然我现在这块还没做好,因为有时一个项目的代码是一块提交的,不像开源框架已经稳定下来,只是做增量部分代码提交

Code Review_第2张图片

可维护性

其实这个跟可读性有点重复的,就像产品一样有各种证书,有各种使用说明文档,比如说药品,每天吃几次每次几粒,吃了会什么反应,如果反应激烈的话怎么回滚,哈哈,开个玩笑。人能回滚那就没了~

代码上还是方法简洁,不会说各种逻辑夹杂在一起,跟炒面一样,或者说印度啊三的电线一样,缠绕得很哇塞。

然后是文档,像开源框架,一般有个readme,贴心的还会有中英文,渣男的体贴,最要命~然后是wiki,各个模块分别实现什么功能,然后设计思想咋样的。

Code Review_第3张图片

可扩展性

这个很明显就是前面两个升级版,前面两个就是能跑就行,能看得懂就行,这个是对代码质量上,能够适应业务长期发展的需求,不会说业务一变,代码重新推倒重来。

  1. 设计模式

这个其实也有套路的,先看业务场景,比如说订单,就会想起状态机设计模式,比如说网关,责任链设计模块,还有对账功能,其实也是采用责任链,每个节点去匹配,然后返回对应的匹配结果。

数据表是很源头的地方,如果设计不好,后面会经常变动。表设计满足第三原则,尽量剥离各个表的依赖,然后主表跟附属表隔开。之前我们基础服务的小伙伴经常把字段冗余到主表里头,结果人家需求一变就凉凉。

  1. DDD

ddd应该是整个架构上的可扩展性,我们可以看到它经常采用一些结构将代码进行隔离,比如说防腐层,将外界api跟内部逻辑拆开,设配器也是为了将接口跟底层实现进行拆分。

当然扩展性也是要适当,比如说业务量不是很大,你就非要上高科技,高并发,我觉得是存在过度设计的问题

代码规范

阿里发了很多版的代码规范,大家可以去参考一下,这样在code review的时候,发现那些显而易见的bug,规避掉低级的问题。

圈复杂度


大家可以去idea 安装下MetricsReloaded插件,它会统计代码圈复杂度

比如说if else的次数,循环多少次,方法的行数,方法里头逻辑多不多。其实这些跟可读性和可维护性是有关系的,就是如果太多的逻辑夹杂在里头,阅读者还是开发者很难维护的,特别是出现问题是时候,无疑是大海捞针。

这里也设计到代码的简洁之道,比如说逻辑判断的时候,有些为空的直接return,而不是跟着其他逻辑一直在里面处理。还有方法不超过80行,嵌套大括号不超过4个,然后太多大家也不好理解这是啥。

还有一种说法:

代码质量看方法能否写成最小单元测试

因为每个单元就一个处理逻辑,非常清晰,如果冗余其他逻辑,应该把他们拆开

Code Review_第4张图片

学习到了吗,如果觉得有帮助的,点赞关注下博主呗~

你可能感兴趣的:(代码复审)