代码审查

代码审查（Code Review，又称代码复查）是通过阅读和评估源代码的方式，确保代码在设计、实现、性能、安全和可维护性等方面满足团队标准与业务需求。

代码审查的目标是"帮助别人变得更好"，而不是"替别人写代码"。

为何要进行代码审查

代码审查的目的不仅是发现缺陷，更是持续提升团队整体工程质量和能力的过程：

角色

角色 职责
作者（Author） 提交改动的人，应在提交前自检并准备好说明。
审查者（Reviewer） 负责从设计、规范、性能、安全等维度提出反馈。
维护者（Maintainer） 对核心模块或仓库质量负责，有最终合并权。
新成员（Observer） 可旁听或参与小型审查，学习代码质量标准。

审查什么

代码审查的关注点包括但不限于以下方面：

  1. **设计合理性**：是否符合系统架构与设计约束。
  2. **可读性与可维护性**：命名、结构、注释是否清晰。
  3. **功能正确性**：是否满足需求，无逻辑或边界错误。
  4. **测试质量**：是否覆盖主要场景，测试是否健壮。
  5. **性能影响**：是否引入明显性能回退。
  6. **安全性**：是否存在潜在安全漏洞。
  7. **兼容性**：是否考虑上下游系统的接口影响。

审查文化

代码质量是集体责任，而非个人担当。

这一原则根植于两个认知基础：

核心三角

代码审查文化的稳定结构由三个顶点构成：

顶点 内涵 失衡后果
心理安全 参与者不会因提出问题或暴露缺陷而受到惩罚 审查沦为形式、问题被掩盖
建设性反馈 意见具体、可操作、指向改进而非评判 演变为情绪对抗或表面敷衍
集体责任 代码属于团队，而非个人所有 审查者推诿、作者防御

审查策略

审查策略的核心是基于风险的差异化投入。审查深度应与变更影响范围和历史故障暴露程度正相关。

变更分级

根据变更对系统的影响范围和深度，将审查投入分为三个层级：

级别 影响特征 审查投入
高风险 核心逻辑、数据库结构、跨模块接口变更 深度审查
中风险 新功能开发、业务逻辑调整 标准审查
低风险 文档更新、UI 样式调整、注释优化 快速审查

内容分级

审查关注点应按三个层级递进展开：

层级 审查焦点 回答的核心问题
设计级 架构约束、模块边界、依赖关系 这样的设计是否符合系统演化方向
实现级 代码逻辑、命名规范、错误处理 代码是否清晰表达了设计意图
部署级 配置变更、环境差异、脚本影响 变更是否引入环境一致性风险

上下文敏感区

以下上下文应触发审查策略的强化调整：

审查标准

审查原则

审查形式

同步评审

开发者现场讲解代码思路与变更内容，审查者同步提问、讨论。 适用于核心模块、复杂逻辑、跨模块变更。

特点：

异步评审

开发者通过工具（如 GitLab MR、Gerrit、GitHub PR）提交代码，由审查者异步评审。

特点：

原则：小而多。 每次提交的变更量应尽量小，以提高审查效率。

代码飞检

代码飞检是由质量负责人或架构师对随机模块或高风险变更进行的独立审查，目标是发现系统性问题、违规实践或潜在技术债。

与常规审查的区别

维度 常规审查（PR/MR） 代码飞检
触发方式 变更驱动（提交代码 → 自动触发） 时间驱动（按周/版本节点定期执行）
审查范围 本次变更（增量） 随机模块或指定模块（存量）
审查者 代码相关开发者 质量负责人/架构师（独立于作者）
关注重点 变更的正确性、一致性 系统性问题、违规模式、技术债
发现问题类型 本次引入的缺陷 历史积累的架构/规范问题

核心差异：常规审查是"防守性"的（阻止问题进入），飞检是"进攻性"的（主动挖掘已存在的系统性问题）。

节奏与沉淀

万物评审

代码审查只是质量体系中的一个环节。 真正的工程文化应做到“万物可评审”，包括：

通过多人参与、视角多样的方式，提升决策的完整性与前瞻性。

评审流程五问

  1. **为什么要做？**（目标与价值）
  2. **怎么做？**（设计与实现）
  3. **哪里做？**（影响范围）
  4. **何时做？**（时机与节奏）
  5. **谁来做？**（责任与角色）

成本与收益分析

评审形式

参与人员

角色 职责
发起者 发起评审，提供材料与背景
主持人 控制节奏，保持讨论聚焦
作者 讲解内容，接受反馈
评审员 提出意见与建议
记录员 记录结论与改进项
团队关键成员 负责最终决策或签核

度量与改进

建立代码审查指标体系，用数据反哺流程优化：

指标 含义
审查覆盖率 被审查提交占比
审查时长 平均从提交到通过时间
缺陷发现率 每次审查发现的有效问题数
审查参与度 团队成员参与情况
审查满意度 审查过程反馈

关联内容（自动生成）