# 代码审查

## 背景

**`Code Review`** 可谓是互联网企业技术部门必备的基本要求。一个好的产品发开一定会存在产品迭代的过程，而一个稳、强的团队必然会有代码审查的流程。什么是代码审阅呢？简单而言：代码审阅者对编码者所编写代码进行查阅、评审。

> 接下来我们深入认识代码审查，掌握为何做？何时做？如何做？



## 为什么要代码审阅

代码审阅与项目协作开发息息相关，少了它就会导致项目开发流程没有形成闭环( 项目不完整 )。从根本上而言，代码审阅是对团队的负责、更是对企业的责任。

根据个人的代码审阅的经历，同一个团队、前期每次审阅时候，即使已经制定项目规范，每次或多或少都存在问题，这些问题大体可以分为**代码问题** 与 **业务问题**两种，具体可以分为如下几类：

- 编码规范

- 技术实现

- 业务规范与实现

- 数据库规范

- 逻辑缺陷等

前期发现的问题大部分都是比较初级的问题，虽然是初级的问题，假设初级问题越多、项目年龄长，绝对会影响项目的扩展性、稳定性等，主要表现为业务迭代不灵活、开发困难。

经过定时( 小迭代 或 功能分支 )代码审阅，效果还是相当不错的！

- 第一、代码质量得到了很高的提升

- 第二、小问题越来越少、甚至可以规避( 响应加入开发规范 )

- 第三、团队之间业务、技术达成一致的共识

所以、**合理的代码审阅是必然的，是对项目代码的负责 以及 对产品的责任**，对于开发者而言、我们也可以从评审增长见识，提高开发者自身水平。

> 很有道理的一句话：项目开发流程缺少**项目规范** 与 **代码审阅** 最容易降低项目质量从而导致项目被重构。



## 代码审阅的目标与原则

代码审查的目的在行业都是公认的，很简单：**提升代码的质量，尽早发现潜在的缺陷，降低修复的成本，同时可以促进开发团队内部知识的共享，帮助开发者更好理解系统的业务与实现**

对于代码审阅的原则而言，不定期地从小版本迭代( `version` ) 或 新功能( `feature` )进行团队或者相关人员进行评审，评审的维度从**架构、业务实现、技术**着手分析。



## 代码审阅流程

大致的审查流程大致如下流程图所示，即

1. 开发者完成开发后，将功能分支提交并提醒审阅者进行代码审查

2. 评审者审阅代码，假设没有存在问题则让开发者将功能分支合并至开发分支，否则组织评审会，指出相应的不合理之处并讨论出可行方案进行更改

3. 开发者根据修改方案进行代码修复，完成后再次提交，返回 `1`

```mermaid
graph TB
    subgraph 团队协作仓库
    merge_code[合并功能分支]
    end
    subgraph 审阅者
    review_code[评审提交代码]
    is_modify{看看是否要修改}
    review_code-->is_modify
    is_modify-- 否 -->merge_code
    is_modify-- 是 -->modify_code
    end
    subgraph 开发者
    push_code[提交分支代码]
    modify_code[修改代码]
    modify_code-- 重新提交 -->push_code
    push_code-->review_code
    end
```



## 代码审阅内容

#### 业务上

> 确保业务定义的功能正常运行 以及 业务后续的可迭代性

- 业务处理

  即功能实现是否能正常运行、满足预期的效果，同时确保业务的合理性 与 可迭代性。

- 业务规范

  使用正确的姿势正确处理业务，尽量禁止特殊处理 或者 歧义方式。

- 规范习惯

  必须编写并更新项目文档、接口文档。

  

#### 代码上

> 必须遵循项目规范，主要是从项目规范审阅，详细查看其它规范章节

- 命名规范

- 日志输出

- 代码注释

- 代码优化

- 数据库规范

- 事务处理

- 代码复用

- 效率与性能( 稳定性、健壮性 )

- 事务处理

- 项目架构目录定义规范

- 可读性、可维护性

- 代码安全性

- 单元测试



## 代码审阅工具


一般代码审阅都是基于小版本 或 新功能，因而使用 `Git`工具和 `IDE`即可。




## 备注

根据开发者提交的说明内容，所以比较代码务必遵循代码提交规范

合理安排代码审阅时间，一般一个功能模块安排1~2个小时，复杂的功能或系统可适当延长。

代码审阅后，审阅者提出修改意见，代码开发者经过沟通后需要尽快修改完善。