# Code Review

> Code architecture review. 当用户需要评审代码架构、讨论设计模式、检查代码质量或进行代码评审时使用此skill。

- Skill: `fengqiliu/code-review` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add fengqiliu/code-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/fengqiliu/code-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: fengqiliu (https://skillmd.com/u/fengqiliu)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/fengqiliu/code-review

---


# Code Architecture Review

代码架构评审技能，从架构角度审查代码质量和设计。

## 评审维度

### 1. 设计模式应用

**正面模式（应采用）**

| 模式 | 适用场景 | 检查点 |
|------|---------|--------|
| Factory Method | 对象创建逻辑复杂 | 是否隐藏创建细节 |
| Strategy | 多种算法/策略 | 是否支持运行时切换 |
| Observer | 事件通知 | 是否解耦观察者和被观察者 |
| Decorator | 动态扩展功能 | 是否避免继承层次过深 |
| Repository | 数据访问抽象 | 是否隔离持久化逻辑 |
| Command | 请求封装 | 是否支持撤销/重做 |

**反面模式（应避免）**

| 模式 | 问题 | 解决方案 |
|------|------|---------|
| God Object | 职责过多 | 拆分为单一职责类 |
| Circular Dependency | 循环依赖 | 引入接口解耦 |
| Shotgun Surgery | 修改扩散 | 合并相关职责 |
| Speculative Generality | 过度设计 | YAGNI 原则 |
| Primitive Obsession | 基础类型堆砌 | 引入 Value Object |

### 2. SOLID 原则检查

```
□ S - Single Responsibility (单一职责)
  - 类是否只有一个变化原因？
  - 方法是否保持简短？

□ O - Open/Closed (开闭原则)
  - 对扩展开放，对修改封闭？
  - 使用继承还是组合？

□ L - Liskov Substitution (里氏替换)
  - 子类能否替换父类？
  - 是否违反继承契约？

□ I - Interface Segregation (接口隔离)
  - 接口是否臃肿？
  - 客户端是否被迫依赖未使用的方法？

□ D - Dependency Inversion (依赖反转)
  - 依赖抽象而非具体？
  - 是否使用依赖注入？
```

### 3. 代码复杂度

| 指标 | 可接受 | 警告 | 不可接受 |
|------|--------|------|---------|
| 方法行数 | < 20 | 20-40 | > 40 |
| 类行数 | < 200 | 200-500 | > 500 |
| 圈复杂度 | < 10 | 10-20 | > 20 |
| 嵌套深度 | < 3 | 3-5 | > 5 |
| 参数个数 | < 3 | 3-5 | > 5 |

### 4. 架构层次检查

```
□ 是否遵循确定的分层架构？
□ 依赖方向是否正确（外层依赖内层）？
□ 是否有跨层直接调用？
□ 核心业务逻辑是否在正确的层？
```

### 5. 错误处理

```
□ 是否有统一的异常处理机制？
□ 异常是否被适当捕获和记录？
□ 是否避免了吞掉异常（空 catch）？
□ 自定义异常是否有意义？
```

### 6. 数据访问

```
□ 是否使用 Repository 模式？
□ 是否存在 N+1 查询问题？
□ 事务边界是否清晰？
□ 是否考虑缓存策略？
```

## 代码评审报告模板

```markdown
# 代码架构评审报告

## 1. 评审概要
- **评审范围**：[文件/模块列表]
- **评审时间**：[日期]
- **整体评级**：[A/B/C/D]

## 2. 主要发现

### 严重问题 (必须修复)
| 问题 | 位置 | 描述 | 建议 |
|------|------|------|------|
|      |      |      |      |

### 中等问题 (建议修复)
| 问题 | 位置 | 描述 | 建议 |
|------|------|------|------|
|      |      |      |      |

### 轻微问题 (可选修复)
| 问题 | 位置 | 描述 | 建议 |
|------|------|------|------|
|      |      |      |      |

## 3. 架构亮点
[做得好的设计决策]

## 4. 改进建议优先级
1. [最优先]
2. [次优先]
3. [后续]

## 5. 总结
[总体评价]
```

## 评审 Checklist

```
评审前
□ 理解需求和业务背景
□ 了解技术栈和约束
□ 确定评审重点

评审中
□ 从整体到局部，从粗到细
□ 记录所有发现（不只是问题，也包括亮点）
□ 标注问题优先级

评审后
□ 整理评审报告
□ 与开发者对齐问题
□ 确认后续行动计划
```

## 常见架构问题速查

| 问题 | 症状 | 解决方案 |
|------|------|---------|
| 循环依赖 | 编译/测试顺序敏感 | 引入接口、依赖倒置 |
| 分散耦合 | 修改一个模块影响多个 | 提取抽象、降低耦合 |
| 逻辑泄漏 | 业务规则散布多处 | 提取到 Domain 层 |
| 过度预判 | 从不使用的基础设施 | YAGNI、渐进设计 |
| 缓存滥用 | 数据不一致 | 明确缓存策略、同步机制 |