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个小时,复杂的功能或系统可适当延长。
代码审阅后,审阅者提出修改意见,代码开发者经过沟通后需要尽快修改完善。