Codereview是什么？为什么需要Codereview？

前言

其实从我毕业到前不久，整个项目流程很少有codereview,所以今天来好好讲讲codereview是什么东西。很多东西存在，它有存在的原因比如说第一家公司的时候，是产品带团队，关注的是结果，关注的是运营数据，至于项目质量，其实产品在这方面经验是很少的。还有另外一个原因是业务太忙了，需求几天搞完，业务都搞不完，哪有时间做这些技术审核。

Codereview有没有必要？Codereview意义在哪里以前没有这个步骤的时候，项目流程也能跑呀对吧，感觉可有可无。其实它是属于项目质量的一环，我们以前经常会出现一些低级bug导致线上问题，或者说写了一堆只有自己能读懂的代码，其他人根本就接手不了。（提高下自己不可替代性是吧，哈哈）Codereview是通过reviewer来进行审核别人提交的代码，通过一定的规则，判断代码是否有问题，然后跟开发者进行沟通解决。

Codereview的时间点

• 开发中：在coding阶段及时发现问题，这样可以减少后续复工的情况，比如说都测试完了才发现问题，你改完问题，人家还要再测试一遍，qa一jio就过去。
• 测试中：我比较习惯这个时候去review的，因为一开始写业务代码的时候，我很烦别人一直打断我的思路，我想一把梭哈，然后后面慢慢修。如果你去理发店剪头发，你就有体会，tony老师会先把边边角角修了，然后才用剪刀进行精修。我们就要根据实际情况进行择时进行codereview

Review内容

Review的目的是为了业务上实现功能，技术上可读性、可维护性、可扩展性，那么对于提交代码也需要关注这些，而不是让代码变成一个屎山，然后大家不断累积上去，最后无法维护，进行重构。逻辑上这个是最基本的要求，如果连逻辑都无法实现功能，那还玩什么自行车‍♀️哈哈。

首先我们看下需求文档，自己上手去系统熟悉下业务，然后看下设计文档，设计文档里头就会有数据库设计，接口罗列，物理架构图，逻辑架构图，还有一些核心的交互对吧，然后再开始看逻辑是不是对的上。

技术上可读性这个很好理解，就是别人一个小白通过你的方法名、注释就能看出你写的是啥玩意，而不是一顿分析，一顿操作，然后还有点闷逼。可读性有什么表现呢？

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

可维护性其实这个跟可读性有点重复的，就像产品一样有各种证书，有各种使用说明文档，比如说药品，每天吃几次每次几粒，吃了会什么反应，如果反应激烈的话怎么回滚，哈哈，开个玩笑。人能回滚那就没了～代码上还是方法简洁，不会说各种逻辑夹杂在一起，跟炒面一样，或者说印度啊三的电线一样，缠绕得很哇塞。然后是文档，像开源框架，一般有个readme，贴心的还会有中英文，渣男的体贴，最要命～然后是wiki，各个模块分别实现什么功能，然后设计思想咋样的。

可扩展性这个很明显就是前面两个升级版，前面两个就是能跑就行，能看得懂就行，这个是对代码质量上，能够适应业务长期发展的需求，不会说业务一变，代码重新推倒重来。设计模式这个其实也有套路的，先看业务场景，比如说订单，就会想起状态机设计模式，比如说网关，责任链设计模块，还有对账功能，其实也是采用责任链，每个节点去匹配，然后返回对应的匹配结果。表数据表是很源头的地方，如果设计不好，后面会经常变动。表设计满足第三原则，尽量剥离各个表的依赖，然后主表跟附属表隔开。之前我们基础服务的小伙伴经常把字段冗余到主表里头，结果人家需求一变就凉凉。DDDddd应该是整个架构上的可扩展性，我们可以看到它经常采用一些结构将代码进行隔离，比如说防腐层，将外界api跟内部逻辑拆开，设配器也是为了将接口跟底层实现进行拆分。当然扩展性也是要适当，比如说业务量不是很大，你就非要上高科技，高并发，我觉得是存在过度设计的问题。

代码规范阿里发了很多版的代码规范，大家可以去参考一下，这样在codereview的时候，发现那些显而易见的bug，规避掉低级的问题。圈复杂度大家可以去idea安装下MetricsReloaded插件，它会统计代码圈复杂度。比如说ifelse的次数，循环多少次，方法的行数，方法里头逻辑多不多。其实这些跟可读性和可维护性是有关系的，就是如果太多的逻辑夹杂在里头，阅读者还是开发者很难维护的，特别是出现问题是时候，无疑是大海捞针。这里也设计到代码的简洁之道，比如说逻辑判断的时候，有些为空的直接return，而不是跟着其他逻辑一直在里面处理。还有方法不超过80行，嵌套大括号不超过4个，然后太多大家也不好理解这是啥。经过分析之后，找到比较复杂那个类，可以看到里面逻辑还是比较多的，可以将他们拆出其他方法里面封装，这样更容易阅读还有一种说法：代码质量看方法能否写成最小单元测试因为每个单元就一个处理逻辑，非常清晰，如果冗余其他逻辑，应该把他们拆开