代码审阅.md 4.5 KB

代码审查

背景

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

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

为什么要代码审阅

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

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

  • 编码规范

  • 技术实现

  • 业务规范与实现

  • 数据库规范

  • 逻辑缺陷等

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

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

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

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

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

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

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

代码审阅的目标与原则

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

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

代码审阅流程

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

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

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

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

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个小时,复杂的功能或系统可适当延长。

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