代码审阅.md 4.5 KB
代码审查
背景
Code Review 可谓是互联网企业技术部门必备的基本要求。一个好的产品发开一定会存在产品迭代的过程，而一个稳、强的团队必然会有代码审查的流程。什么是代码审阅呢？简单而言：代码审阅者对编码者所编写代码进行查阅、评审。
接下来我们深入认识代码审查，掌握为何做？何时做？如何做？
为什么要代码审阅
代码审阅与项目协作开发息息相关，少了它就会导致项目开发流程没有形成闭环( 项目不完整 )。从根本上而言，代码审阅是对团队的负责、更是对企业的责任。
根据个人的代码审阅的经历，同一个团队、前期每次审阅时候，即使已经制定项目规范，每次或多或少都存在问题，这些问题大体可以分为代码问题 与 业务问题两种，具体可以分为如下几类：
编码规范
技术实现
业务规范与实现
数据库规范
逻辑缺陷等
前期发现的问题大部分都是比较初级的问题，虽然是初级的问题，假设初级问题越多、项目年龄长，绝对会影响项目的扩展性、稳定性等，主要表现为业务迭代不灵活、开发困难。
经过定时( 小迭代 或 功能分支 )代码审阅，效果还是相当不错的！
第一、代码质量得到了很高的提升
第二、小问题越来越少、甚至可以规避( 响应加入开发规范 )
第三、团队之间业务、技术达成一致的共识
所以、合理的代码审阅是必然的，是对项目代码的负责 以及 对产品的责任，对于开发者而言、我们也可以从评审增长见识，提高开发者自身水平。
很有道理的一句话：项目开发流程缺少项目规范 与 代码审阅 最容易降低项目质量从而导致项目被重构。
代码审阅的目标与原则
代码审查的目的在行业都是公认的，很简单：提升代码的质量，尽早发现潜在的缺陷，降低修复的成本，同时可以促进开发团队内部知识的共享，帮助开发者更好理解系统的业务与实现
对于代码审阅的原则而言，不定期地从小版本迭代( version ) 或 新功能( feature )进行团队或者相关人员进行评审，评审的维度从架构、业务实现、技术着手分析。
代码审阅流程
大致的审查流程大致如下流程图所示，即
开发者完成开发后，将功能分支提交并提醒审阅者进行代码审查
评审者审阅代码，假设没有存在问题则让开发者将功能分支合并至开发分支，否则组织评审会，指出相应的不合理之处并讨论出可行方案进行更改
开发者根据修改方案进行代码修复，完成后再次提交，返回
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个小时，复杂的功能或系统可适当延长。
代码审阅后，审阅者提出修改意见，代码开发者经过沟通后需要尽快修改完善。