afine907 Code Review — 代码审查技能
对代码进行系统性多维度审查，输出结构化审查报告。
Goal
对代码变更进行多维度审查，输出结构化审查报告。检查正确性、安全性、性能、可维护性、测试覆盖
Trigger
- 用户要求"review代码"、"审查代码"、"检查代码质量"
- PR 提交前的代码自查
- 学习代码审查方法论
工作流程
代码变更 → 维度分析 → 问题标注 → 严重性分级 → 输出报告
审查维度
1. 正确性 (Correctness)
| 检查项 | 说明 |
|---|---|
| 逻辑错误 | 条件判断、循环边界、短路求值 |
| 空值处理 | None/null 检查、Optional 解包 |
| 类型安全 | 隐式类型转换、类型混用 |
| 并发安全 | 竞态条件、死锁、线程安全 |
| 错误处理 | 异常捕获范围、错误传播、资源清理 |
2. 安全性 (Security)
| 检查项 | 说明 |
|---|---|
| 注入攻击 | SQL、XSS、命令注入、路径遍历 |
| 认证授权 | 权限检查缺失、越权访问 |
| 敏感数据 | 密钥硬编码、日志泄露、明文存储 |
| 输入验证 | 信任外部输入、未校验边界 |
| 依赖安全 | 已知漏洞的依赖版本 |
3. 性能 (Performance)
| 检查项 | 说明 |
|---|---|
| 算法复杂度 | O(n²) 或更高的循环嵌套 |
| N+1 查询 | 循环中的数据库/HTTP 调用 |
| 内存使用 | 大对象复制、未释放资源 |
| 缓存利用 | 重复计算、可缓存的查询 |
| 异步优化 | 可并行的串行操作 |
4. 可维护性 (Maintainability)
| 检查项 | 说明 |
|---|---|
| 命名清晰 | 变量/函数名是否自解释 |
| 函数长度 | 单函数超过50行需拆分 |
| 重复代码 | 可提取为公共函数的重复逻辑 |
| 职责单一 | 一个函数/类做太多事情 |
| 魔法数字 | 硬编码的常量应提取为命名常量 |
5. 测试覆盖 (Testing)
| 检查项 | 说明 |
|---|---|
| 测试存在 | 新增代码是否有对应测试 |
| 边界覆盖 | 测试是否覆盖边界条件 |
| 异常覆盖 | 测试是否覆盖错误路径 |
| 可测试性 | 代码是否便于测试（依赖注入等） |
输出报告格式
# 代码审查报告
## 概览
- 审查文件：{文件列表}
- 审查时间：{时间}
- 总体评级：{A/B/C/D}
## 统计
| 严重性 | 数量 |
|--------|------|
| 🔴 Critical | {n} |
| 🟠 Major | {n} |
| 🟡 Minor | {n} |
| 🔵 Suggestion | {n} |
## 问题详情
### 🔴 [Critical] {问题标题}
- **文件**: `{file}:{line}`
- **维度**: 安全性
- **问题描述**: {具体描述}
- **影响**: {可能造成的后果}
- **建议修复**:
```code
// 修复前
{原始代码}
// 修复后
{建议代码}
🟠 [Major] {问题标题}
...
🟡 [Minor] {问题标题}
...
🔵 [Suggestion] {建议标题}
...
亮点
- {代码中做得好的地方}
总结
{整体评价和改进建议}
## 严重性定义
| 级别 | 含义 | 处理要求 |
|------|------|----------|
| 🔴 Critical | 会导致崩溃、数据丢失、安全漏洞 | 必须修复 |
| 🟠 Major | 影响功能正确性或性能 | 强烈建议修复 |
| 🟡 Minor | 影响代码质量或可维护性 | 建议修复 |
| 🔵 Suggestion | 改进建议，非必须 | 可选采纳 |
## Example
用户: review 这个 PR 的代码变更
输出:
代码审查报告
概览
- 文件变更: 5 个文件, +120/-30 行
- 审查维度: 正确性、安全性、性能
问题详情
🔴 [BUG] user.py:45 - SQL 注入风险 🟡 [PERF] db.py:23 - N+1 查询
亮点
✅ 错误处理完善 ✅ 类型提示完整
## 快速使用
审查当前变更
review 当前代码变更
审查指定文件
review src/auth/login.py
审查 PR diff
review 这个 PR 的代码变更
只关注安全性
从安全性角度审查这段代码
快速审查（只报 Critical 和 Major）
快速 review 一下这段代码
## 审查原则
1. **对事不对人** — 审查代码，不审查人
2. **给出理由** — 每个问题说明 WHY，不只是 WHAT
3. **提供方案** — 不只指出问题，还要给出修复建议
4. **肯定亮点** — 好的代码也要表扬
5. **聚焦重点** — 优先关注高严重性问题