当前位置：首页 > news >正文

Code Review

news 来源：原创 2024/5/19 22:57:51

前言

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

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

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

code review有没有必要？

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vku3l3Sr-1661961275760)(https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/43ba08bb658245d7955889fcb0b6a9f7~tplv-k3u1fbpfcp-watermark.image?)]

code review意义在哪里

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

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

code review的时间点

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

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

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

review内容

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

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

逻辑上

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

技术上

可读性

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

可读性有什么表现呢？

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-C1xzpvbT-1661961275762)(https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f3d08b34ab284e8aabe6df3f2b0d06ea~tplv-k3u1fbpfcp-watermark.image?)]

可维护性

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

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

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

在这里插入图片描述

可扩展性

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

设计模式

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

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

DDD

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

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

代码规范

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

圈复杂度

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

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

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

还有一种说法：

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

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hcKyT2uj-1661961275763)(https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/bf151beed01542e8a052820925ac1641~tplv-k3u1fbpfcp-watermark.image?)]