代码审查
代码审查也叫代码复查,即通过阅读代码的方式来检查代码是否符合要求
谷歌代码审查指南:https://jimmysong.io/eng-practices/docs/review/
- 帮助别人成长,而不是帮他写代码
 
为何要代码审查
代码审查是提高代码质量,提前发现 BUG ,统一团队代码规范,促进团员成长的一个重要途径
针对目标使用数据驱动,监测相关目标的推动因素,达到一个正反馈,从而促进质量的提升
谁来审查
审查什么
- 设计规范
 - 可读性与可维护性
 - 是否有错误(需求与BUG)
 - 测试代码是否良好
 - 性能
 - 安全性
 
审查策略
必备检查项
业务高压线
历史故障点
变更分级
内容分级
审查标准
- 首要原则是保障质量
 - 妥协完美 不要追求过度完美
 - 锦上添花
 
审查原则
- 遵循代码规范
 - 尊重个人设计
 - 不带个人情感
 
审查工具
- git
 - Upsource
 
审查形式
原则上,每次被审查的代码都应保持较少的水平,审查这些代码的人员一般都要求是经验较为丰富的高级开发人员,不仅可以通过审查发现代码的缺陷、不足,同时对于研发来说审查也是高级开发人员向团队新手分享知识的一种途径,对于测试来说也可以明确变更的影响范围及提升系统质量
审查的过程应该是纯粹的,禁止有情感、绩效因素。
同时审查也不应该是保证代码规范的手段,代码规范应该有工具化、自动化的手段
- 沟通而非对抗
 - 不要自负
 - 小而多
 - 不要太正式
 - 一个人的代码最多两人审查就够了
 
CR讲解
开发者讲解代码,评审者听取并发现问题、提问讨论
针对分歧,当场解决
- 同步沟通 精力大
 - 适用于核心代码
 
CR Review
开发者异步提交给评审者
- 异步沟通
 - 对团队整体水平要求较高
 
审查内容
- 功能性bug
 - 逻辑优化
 - 代码复用
 - 执行效率
 - 安全性
 - 代码规范
 - 测试覆盖
 - 扩展性
 - 过度的设计
 
代码飞检
万物评审
- 需求
 - 架构
 - 计划
 - ...
 
通过多人参与集思广益,多样的视角,不同的观点发现其中存在的问题
为什么要做,怎么做,哪里做,何时做,谁来做?
成本与收益比? 目标是什么,怎么执行,得到什么结果
评审形式
- 会议评审
 - 桌面评审
 
参与人
- 发起者
 - 主持人
 - 作者
 - 评审员
- 关键
 - 可选
 
 - 记录员
 - 团队关键人员