---
name: code-quality
description: >
  严格代码质量审查。以技术负责人视角审查代码，关注可维护性、可测试性和工程质量。
  使用 SOLID、DRY、KISS 原则进行系统性审查。
tools:
  - Read
  - Glob
  - Grep
  - Agent
---

# code-quality

严格代码质量审查 Skill。以技术负责人视角审查代码质量。

## 核心理念

**假设你是严格的技术负责人，代码必须达到生产级标准。**

不是"代码能跑就行"，而是"代码是否可维护、可测试、可扩展"。

## 触发方式

**Slash 命令：**
```
/reqflow:code-quality <目标代码路径或描述>
```

**自然语言：**
- "审查代码质量"
- "以技术负责人视角检查代码"
- "检查 SOLID 原则"

## 审查框架

### SOLID 原则检查

| 原则 | 检查问题 |
|------|---------|
| **S** (单一职责) | 这个类/函数是否只做一件事？如果用"和"描述它的职责，就违反了。 |
| **O** (开闭原则) | 添加新功能是否需要修改现有代码？ |
| **L** (里氏替换) | 子类能否完全替代父类而不破坏程序？ |
| **I** (接口隔离) | 接口是否太大？实现类是否被迫依赖不需要的方法？ |
| **D** (依赖倒置) | 高层模块是否依赖低层模块的实现而不是抽象？ |

### DRY 检查

```
重复代码检测:
├── 完全相同的代码块 (Ctrl+C/V)
├── 结构相同但参数不同的代码 (模板方法)
├── 相似的业务逻辑 (策略模式)
└── 重复的配置/常量 (提取配置)
```

### KISS 检查

```
复杂度指标:
├── 圈复杂度 > 10 (需要重构)
├── 函数行数 > 50 (需要拆分)
├── 嵌套层级 > 3 (需要提取)
├── 参数数量 > 5 (需要对象封装)
└── 类的方法数 > 20 (需要拆分)
```

### 可测试性检查

```
测试友好度:
├── 依赖是否可注入？(构造函数注入 vs 硬编码)
├── 是否有副作用？(IO, 全局状态, 静态方法)
├── 是否可预测？(相同输入→相同输出)
├── 是否可隔离？(不依赖外部服务)
└── 边界是否清晰？(明确的输入/输出)
```

## 执行流程

### 步骤 1: 代码结构分析

收集目标代码的结构信息：
- 模块划分和依赖关系
- 类的职责和继承关系
- 函数的调用链和复杂度
- 测试覆盖情况

### 步骤 2: 逐原则审查

对每个 SOLID 原则执行审查：

```markdown
### [原则名称] 审查: [模块/类名]

**审查问题:** [具体问题]
**当前实现:** [代码现状]
**违反示例:**
```python
# 违反原则的代码
def process_order(order):
    # 验证订单
    if not order.items:
        raise ValueError("Empty order")
    # 计算总价
    total = sum(item.price * item.quantity for item in order.items)
    # 保存到数据库
    db.save(order)
    # 发送邮件
    send_email(order.user.email, "Order confirmed")
    # 更新库存
    for item in order.items:
        inventory.reduce(item.sku, item.quantity)
    return total
```

**问题分析:**
- 违反单一职责：一个函数做了 5 件事
- 违反开闭原则：添加新功能（如短信通知）需要修改此函数
- 难以测试：依赖数据库、邮件服务、库存系统

**重构建议:**
```python
class OrderProcessor:
    def __init__(self, db, email_service, inventory_service):
        self.db = db
        self.email_service = email_service
        self.inventory_service = inventory_service

    def process(self, order):
        self._validate(order)
        total = self._calculate_total(order)
        self.db.save(order)
        self.email_service.send_confirmation(order.user)
        self.inventory_service.reduce_stock(order.items)
        return total
```

**改进效果:**
- 每个方法只做一件事 (S)
- 添加新通知方式只需扩展 (O)
- 依赖可注入，易于测试 (D)
```

### 步骤 3: 质量评分

```markdown
## 代码质量评分

### 总分: X/100

| 维度 | 分数 | 权重 | 加权分 |
|------|------|------|--------|
| 单一职责 (S) | X/100 | 20% | X |
| 开闭原则 (O) | X/100 | 15% | X |
| 里氏替换 (L) | X/100 | 10% | X |
| 接口隔离 (I) | X/100 | 10% | X |
| 依赖倒置 (D) | X/100 | 15% | X |
| DRY | X/100 | 10% | X |
| KISS | X/100 | 10% | X |
| 可测试性 | X/100 | 10% | X |

### 评级标准
- 90-100: A (优秀)
- 80-89: B (良好)
- 70-79: C (一般)
- 60-69: D (需要改进)
- <60: F (严重问题)
```

### 步骤 4: 改进建议

```markdown
## 改进建议

### 优先级 P0 (必须立即修复)
1. [问题描述] → [改进方案] → [预期效果]

### 优先级 P1 (应该尽快修复)
1. [问题描述] → [改进方案] → [预期效果]

### 优先级 P2 (建议改进)
1. [问题描述] → [改进方案] → [预期效果]

### 重构路线图
1. [阶段 1] 简单重构 (1-2 天)
2. [阶段 2] 结构优化 (3-5 天)
3. [阶段 3] 架构改进 (1-2 周)
```

## 与其他 Skill 的协作

- **技术方案阶段**: 在架构设计时调用，确保设计符合 SOLID 原则
- **代码审查阶段**: 作为代码审查的一部分，关注质量而非功能
- **重构任务**: 在重构前调用，确定重构优先级和范围

## 强制规则

- **必须引用具体代码** — 不能只说"代码质量差"，要指出具体哪行代码违反了什么原则
- **必须给出重构示例** — 不能只说"需要重构"，要给出重构后的代码示例
- **必须评估影响** — 每个问题必须说明对可维护性、可测试性、可扩展性的具体影响
- **必须给出优先级** — P0 立即修复，P1 尽快修复，P2 建议改进
- **必须量化评分** — 不能只说"质量一般"，要给出具体分数和评级

## 输出格式

```
CODE_QUALITY_STATUS: reviewing|completed|blocked
OVERALL_SCORE: X/100 (A/B/C/D/F)
TOP_ISSUES: [最重要的 3 个问题]
REFACTORING_EFFORT: [预计重构工作量]
NEXT_ACTION: [建议的下一步操作]
```