代码审查（Code Review）
代码审查（Code Review，又称代码复查）是通过阅读和评估源代码的方式，确保代码在设计、实现、性能、安全和可维护性等方面满足团队标准与业务需求。
参考资料：
- 谷歌工程实践（代码审查指南）：[https://jimmysong.io/eng-practices/docs/review/](https://jimmysong.io/eng-practices/docs/review/)
核心理念：代码审查的目标是“帮助别人变得更好”，而不是“替别人写代码”。
一、为何要进行代码审查
代码审查的目的不仅是发现缺陷，更是持续提升团队整体工程质量和能力的过程：
- **提升质量：** 早期发现设计或实现问题，减少生产缺陷。
- **促进学习：** 审查过程即知识共享过程，促进团队成员成长。
- **规范一致性：** 推动统一的编码风格和最佳实践。
- **增强可维护性：** 审查确保代码清晰、结构合理、易于理解和修改。
- **提升团队信任与协作：** 审查促进沟通，减少技术孤岛。
- **数据驱动改进：** 通过量化指标（如审查时长、缺陷发现率）反向优化研发流程。
二、谁来审查
| 角色 | 职责 |
|---|---|
| 作者（Author） | 提交改动的人，应在提交前自检并准备好说明。 |
| 审查者（Reviewer） | 负责从设计、规范、性能、安全等维度提出反馈。 |
| 维护者（Maintainer） | 对核心模块或仓库质量负责，有最终合并权。 |
| 新成员（Observer） | 可旁听或参与小型审查，学习代码质量标准。 |
原则上：代码由作者外的至少一名高级开发人员审查。对于核心或高风险变更，应由两人以上共同审查。
三、审查什么
代码审查的关注点包括但不限于以下方面：
- **设计合理性**：是否符合系统架构与设计约束。
- **可读性与可维护性**：命名、结构、注释是否清晰。
- **功能正确性**：是否满足需求，无逻辑或边界错误。
- **测试质量**：是否覆盖主要场景，测试是否健壮。
- **性能影响**：是否引入明显性能回退。
- **安全性**：是否存在潜在安全漏洞。
- **兼容性**：是否考虑上下游系统的接口影响。
四、审查策略
4.1 必备检查项
- 符合团队编码规范（格式化、命名、日志、异常处理等）
- 无敏感信息（密码、token、个人数据）
- 变更说明完整，commit 信息规范
- 单元测试或集成测试通过
4.2 业务高压线
- 资金流、计费逻辑、权限校验等核心路径必须二次审查
- 不得绕过统一安全框架或认证逻辑
4.3 历史故障点
- 曾出现过线上事故的模块，必须增加交叉审查
- 参考历史缺陷记录重点关注薄弱点
4.4 变更分级
| 级别 | 示例 | 审查要求 |
|---|---|---|
| 高风险 | 核心逻辑、数据库结构、跨模块接口 | ≥2人审查 |
| 中风险 | 新功能、业务逻辑调整 | 1人审查 |
| 低风险 | 文档更新、UI微调、注释优化 | 可快速审查 |
4.5 内容分级
- **设计级**：评估架构与实现思路
- **实现级**：关注代码实现细节
- **部署级**：审查配置、脚本、环境影响
五、审查标准
- **以质量为首要目标。**
- **务实优先于完美。**若存在更优但非关键性方案，不应阻塞交付。
- **积极反馈，鼓励改进。**提出问题时应附带改进建议。
- **记录结论。**对争议和重大决策应记录，便于后续回溯。
六、审查原则
- **遵循规范，不主观臆断。**
- **尊重作者设计，不带情绪化批评。**
- **注重沟通，而非对抗。**
- **小步快跑，频繁审查。**
- **关注问题根因，而非表象。**
七、审查形式
7.1 同步评审（CR讲解）
开发者现场讲解代码思路与变更内容，审查者同步提问、讨论。适用于核心模块、复杂逻辑、跨模块变更。
特点：
- 实时沟通效率高
- 能快速达成共识
- 但耗费精力较大，不宜频繁使用
7.2 异步评审（CR Review）
开发者通过工具（如 GitLab MR、Gerrit、GitHub PR）提交代码，由审查者异步评审。
特点：
- 异步沟通灵活
- 适合常规开发流程
- 对团队自律和代码表达要求较高
原则：小而多。每次提交的变更量应尽量小，以提高审查效率。
八、审查工具
| 工具 | 特点 |
|---|---|
| Git / GitLab / GitHub | 最常用，支持 MR/PR 工作流 |
| Gerrit | 适合大型企业级项目，支持严格权限控制 |
| Upsource | JetBrains 提供的专业代码审查平台 |
| SonarQube | 静态扫描结合人工审查，提升整体质量 |
| Lint 工具 | 自动化格式和规范检查，减少低级问题 |
九、代码飞检（Code Spot Check）
代码飞检是由质量负责人或架构师对随机模块或高风险变更进行独立审查。目标是发现系统性问题、违规实践或潜在技术债。
- 可按周或按版本节点评估
- 飞检结果应沉淀为改进清单与团队培训材料
十、万物评审（Review Everything）
代码审查只是质量体系中的一个环节。真正的工程文化应做到“万物可评审”，包括：
- 需求评审
- 设计/架构评审
- 测试计划评审
- 运维/发布计划评审
- 事故复盘评审
通过多人参与、视角多样的方式，提升决策的完整性与前瞻性。
10.1 评审流程五问
- **为什么要做？**（目标与价值）
- **怎么做？**（设计与实现）
- **哪里做？**（影响范围）
- **何时做？**（时机与节奏）
- **谁来做？**（责任与角色）
10.2 成本与收益分析
- 明确目标产出
- 控制审查成本
- 量化改进效果（如缺陷率下降、交付周期缩短）
10.3 评审形式
- **会议评审：** 集中讨论重大方案
- **桌面评审：** 小范围快速确认实现细节
10.4 参与人员
| 角色 | 职责 |
|---|---|
| 发起者 | 发起评审，提供材料与背景 |
| 主持人 | 控制节奏，保持讨论聚焦 |
| 作者 | 讲解内容，接受反馈 |
| 评审员 | 提出意见与建议 |
| 记录员 | 记录结论与改进项 |
| 团队关键成员 | 负责最终决策或签核 |
十一、度量与改进（可选）
建立代码审查指标体系，用数据反哺流程优化：
| 指标 | 含义 |
|---|---|
| 审查覆盖率 | 被审查提交占比 |
| 审查时长 | 平均从提交到通过时间 |
| 缺陷发现率 | 每次审查发现的有效问题数 |
| 审查参与度 | 团队成员参与情况 |
| 审查满意度 | 审查过程反馈 |
十二、总结
代码审查不是形式，而是一种工程文化。它让“代码质量”从个人责任变为团队共识。
审查的目标是更好的产品、更强的团队和更健康的技术生态。