代码审查（Code Review）不是找茬，而是防止"今天写的代码成为明天的技术债"。本节介绍团队可立即落地的轻量级审查流程。
8.2.1 审查流程设计
采用"三级把关"模式，避免过度依赖人工：
- 提交前自检（自动化）
- 本地运行 lint 工具（ESLint/Checkstyle/SpotBugs），确保零警告
- 单元测试覆盖率不低于团队设定的阈值（通常60%-80%）
- 使用 pre-commit 钩子拦截明显违规（如 console.log 未删除、密码硬编码）
- 同行评审（人工）
- 通过 GitLab/GitHub 发起 Merge Request，指定至少1名非作者审查
- 控制评审量：单次 MR 代码行数不超过 400 行，超过则拆分（研究表明，超过此数量缺陷发现率骤降）
- 时间盒：评审应在提交后 24 小时内完成，避免阻塞开发流
- 架构师抽检（抽样）
- 针对核心模块（支付、权限、事务）进行业务逻辑复核
- 检查接口设计是否符合既定规范（RESTful 路径命名、版本控制策略）
8.2.2 审查清单（Checklist）
审查者对照以下维度勾选，避免遗漏：
- 逻辑正确性：边界条件处理（空数组、超大数值）、并发场景（Race Condition）、资源释放（数据库连接、文件句柄）
- 可读性：函数长度是否超过 50 行？命名是否反映真实意图（避免
processData这类模糊命名）？注释是否解释了"为什么"而非"做什么"？ - 安全性：SQL 是否使用参数化查询？用户输入是否做转义？敏感操作是否有日志审计？
- 性能：循环内是否包含数据库查询？是否可改为批量操作？大对象是否考虑流式处理？
8.2.3 静态质量分析
接入 SonarQube 或 SonarCloud 建立质量门禁：
| 指标 | 合格线 | 说明 |
|------|--------|------|
| 圈复杂度 | ≤10 | 单个函数分支过多需重构 |
| 代码重复率 | ≤3% | 禁止复制粘贴式编程，重复逻辑提取公共方法 |
| 技术债务 | ≤5 天 | 基于规则估算修复所有异味代码所需时间 |
| 测试覆盖率 | 新增代码≥80% | 只统计变更行，避免历史包袱干扰 |
门禁拦截：MR 合并前必须通过质量门禁，阻断"破窗效应"。
8.2.4 实用技巧
- 角色分离：作者负责讲解代码意图，审查者负责质疑假设，避免"作者沉默，审查者挑刺"的尴尬
- 工具辅助：使用 Review Board 或 GitHub Suggestions 直接在代码行上提修改建议，减少口头描述歧义
- 例外处理：紧急热修复（Hotfix）可事后补审，但需在 24 小时内完成追溯审查并记录原因
- 数据驱动：每月统计"审查发现缺陷密度"（每千行代码发现的 Bug 数），低于 0.5 说明审查流于形式，高于 3.0 可能审查过严影响效率
常见误区提醒：
- 不要纠结代码格式（缩进、空格），这些应交给自动化工具（如 Prettier、Spotless）
- 不要追求完美，优先拦截"会出生产事故的代码"，而非"不够优雅的代码"
- 避免"一言堂"，即使资深开发者也应接受团队审查，知识在讨论中传递
代码审查的终极指标是团队整体代码水平的提升，而非找出多少 Bug。当初级开发者通过审查学会防御性编程时，审查的价值才真正体现。