代码审查技能

一种结构化的代码审查方法，兼顾全面性与效率。

核心原则

1. 审查代码，而非作者 — 假设善意，专注于工作本身。
2. 具体且建设性 — 每条评论都应有明确的操作建议。
3. 按严重程度优先级排序 — 并非所有问题同等重要。
4. 自信地批准 — 不要批准自己不愿维护的代码。

审查关注点

🔴 严重 — 合并前必须修复

• 安全漏洞（如 SQL 注入、身份验证绕过、代码中泄露密钥）
• 数据丢失风险（缺少校验、未受保护的删除操作）
• 竞态条件和并发错误
• 可能导致生产环境崩溃的问题

🟡 重要 — 合并前应修复

• 错误处理缺失
• 性能问题（如 N+1 查询、缺少索引、内存泄漏）
• 关键路径缺乏测试覆盖
• 错误响应不一致
• 违反团队编码规范的代码

🟢 小瑕疵 — 可考虑修复

• 命名不够清晰
• 被注释掉的代码
• 微小的格式不一致
• 过于复杂的单行表达式

审查工作流程

第一步：理解上下文

1. 阅读 PR 描述及关联的议题/工单
2. 明确该 PR 的目标
3. 理清变更范围

第二步：初步扫描

快速检查以下内容：

• 明显的 bug 或逻辑错误
• 安全隐患
• 缺失的测试
• 重大变更

第三步：深入审查

针对每个修改的文件：

1. 仔细阅读差异（diff）
2. 与设计文档交叉核对
3. 检查对现有功能的潜在影响
4. 验证测试覆盖率

第四步：分类并评论

对于发现的每个问题，按以下格式分类并评论：

[🔴 严重] <问题标题>
问题描述。
建议修复方式： <具体操作>

[🟡 重要] <问题标题>
问题描述。
建议修复方式： <具体操作>

[🟢 小瑕疵] <问题标题>
可选建议。

第五步：做出决定

PR 描述检查清单

良好的 PR 描述应包含：

• [ ] 做了什么 — 变更的简要概述
• [ ] 为什么做 — 业务或技术动机
• [ ] 如何实现 — 采取的总体方案
• [ ] 测试情况 — 如何进行测试
• [ ] 截图 — UI 变更（前后对比）
• [ ] 破坏性变更 — 是否存在 API 或接口变更
• [ ] 相关议题 — 工单链接

审查评论模板

开始审查

我已审查此 PR。反馈如下：

**审查范围：** [文件/模块]
**本地测试：** [是/否，附详细说明]

批准

✅ **批准** — 代码质量良好，可合并。
少量建议（非阻塞性）：
- [小瑕疵 1]
- [小瑕疵 2]

请求修改

🔄 **请求修改** — 请在合并前解决以下问题：

**严重：**
1. [问题] — [修复建议]

**重要：**
2. [问题] — [修复建议]

阻止合并

❌ **阻止合并** — 本 PR 引入了必须解决的严重问题：

[严重问题的详细描述]

各语言/框架注意事项

Go

• 检查每个函数调用的 error 处理
• 验证 context.Context 的传递
• 检查 defer 是否用于资源清理
• 查看是否存在 goroutine 泄漏（使用 go vet）
• 审查 SQL 查询构建方式（避免字符串拼接）

TypeScript/Node.js

• 检查 async/await 的错误处理
• 验证 API 处理器中的输入校验
• 查找内存泄漏模式（如事件监听器未移除）
• 检查依赖注入模式
• 审查 any 类型的使用

Python

• 检查异常处理
• 验证数据库连接是否正确关闭
• 检查是否正确使用 with 语句
• 审查装饰器使用是否带来副作用
• 检查类型提示的完整性

Java/Kotlin

• 检查异常处理与日志记录
• 验证资源清理（try-with-resources）
• 审查 Spring 注解使用
• 检查线程安全问题
• 检查事务边界

自动化工具补充

代码审查应作为自动化工具的补充（而非替代）：

• 代码检查器（Linter） — 格式与风格规范
• 类型检查器 — 类型安全性
• SAST 扫描器 — 安全漏洞检测
• 覆盖率工具 — 测试覆盖率统计

始终确认自动化工具遗漏的内容。

文件结构

code-review/
├── SKILL.md
└── references/
    ├── review-checklist.md
    ├── comment-templates.md
    ├── severity-classification.md
    └── per-language-notes/
        ├── go.md
        ├── typescript.md
        ├── python.md
        └── java.md