code-review

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

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 查询问题？
□ 事务边界是否清晰？
□ 是否考虑缓存策略？

代码评审报告模板

# 代码架构评审报告

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

## 2. 主要发现

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

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

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

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

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

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

评审 Checklist

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

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

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

常见架构问题速查

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