# Architecture Evaluator

> Architecture Evaluator

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

---


# 架构评估与改进 (Architecture Evaluator)

## 任务目标

本子技能帮助用户评估现有系统架构的质量，识别问题根因，并提供可执行的重构或改进建议。覆盖反模式检测、质量指标打分、技术债务评估和演进路线图制定。

---

## 四阶段评估流程

```
数据收集 → 多维评分 → 问题诊断 → [用户确认] → 改进方案 → 路线图
```

### 阶段 1: 数据收集

**必填信息**：
- 当前系统的核心业务目标（原始文档或口头描述）
- 代码库概况（语言、框架、代码行数、模块数量）
- 当前遇到的具体痛点（性能瓶颈？维护困难？bug 频发？）

**选填信息**（缺失则基于代码分析推断）：
- 架构文档 / 设计文档（如有）
- 测试覆盖率数据
- 线上监控数据（延迟、错误率、资源使用）
- 团队规模和开发流程

---

### 阶段 2: 多维评分

按 P0-P4 优先级对现有架构进行评分（1-10 分）：

| 维度 | 权重 | 评分 | 说明 |
|------|------|------|------|
| **业务对齐度** | P0 | ?/10 | 代码是否仍反映原始业务目标？ |
| **可维护性** | P1 | ?/10 | 模块独立性、重复代码、圈复杂度 |
| **可扩展性** | P1 | ?/10 | 新增需求是否需要大改？OCP 遵从度 |
| **性能** | P2 | ?/10 | 慢查询、资源瓶颈、缓存命中率 |
| **安全性** | P3 | ?/10 | OWASP Top 10 风险 |
| **成本效率** | P4 | ?/10 | 资源利用率、云成本 |

**评分说明**：
- 1-3：严重问题，需立即处理
- 4-6：需改进，计划内修复
- 7-8：较好，有优化空间
- 9-10：优秀

---

### 阶段 3: 问题诊断

#### 3.1 反模式检测清单

| 类别 | 反模式 | 检测线索 | 严重度 |
|------|--------|---------|--------|
| **架构级** | 上帝类 (God Class) | 单个类 > 1000 行 | 🔴 P0 |
| **架构级** | 循环依赖 | A→B→A 的模块依赖链 | 🔴 P0 |
| **架构级** | 散弹式修改 | 改一个需求需要改 N 个文件 | 🟠 P1 |
| **架构级** | 依恋情结 | 一个方法过度依赖另一个类的数据 | 🟡 P2 |
| **代码级** | 过长函数 | 单个函数 > 50 行 | 🟡 P2 |
| **代码级** | 过多参数 | 函数参数 > 4 个 | 🟢 P3 |
| **代码级** | 魔法数字 | 硬编码 0.8、3600 等无解释常量 | 🟢 P3 |
| **代码级** | 重复代码 | 相同逻辑出现 3+ 处 | 🟠 P1 |

#### 3.2 技术债务评估

```mermaid
graph LR
    subgraph "技术债务分布"
        A[架构债务 45%] --> D[Total]
        B[代码债务 30%] --> D
        C[测试债务 15%] --> D
        E[文档债务 10%] --> D
    end
```

评估维度：
- **修复所需人天**：估算
- **风险等级**：低 / 中 / 高 / 危急
- **对业务的影响**：阻塞新功能？降低开发速度？

---

### 阶段 4: 改进方案与路线图

#### 4.1 改进建议（每个建议必须包含权衡分析）

**示例**：

| 建议 | 将 God Class 拆分为多个单一职责类 |
|------|----------------------------------|
| **优点** | 可维护性提升 60%，新增功能无需修改核心类 |
| **缺点 / 成本** | 需要 3-5 人天，可能影响现有功能稳定性 |
| **前置条件** | 需要有足够的测试覆盖（当前覆盖率 30%，建议先补测试） |
| **不适用场景** | 系统即将重写或废弃时，不值得投入 |

#### 4.2 分阶段演进路线图

```mermaid
gantt
    title 架构改进路线图
    dateFormat  YYYY-MM-DD
    section Phase 1 (Quick Wins)
    添加缺失的测试覆盖      :a1, 2026-07-01, 5d
    提取魔法数字为常量      :a2, after a1, 3d
    section Phase 2 (核心重构)
    拆分 God Class          :b1, after a2, 10d
    打破循环依赖            :b2, after b1, 7d
    section Phase 3 (架构演进)
    引入消息队列解耦        :c1, after b2, 14d
    模块化拆分              :c2, after c1, 21d
```

---

## 输出模板

### 高层执行摘要（默认必显）

```
# 架构评估报告：{项目名称}

## 总体评分
可维护性: 5/10 | 性能: 7/10 | 安全性: 6/10 | 成本: 8/10

## 核心发现
🔴 严重: God Class `OrderManager` 1200 行，修改风险极高
🟠 警告: 模块间存在循环依赖 (A→B→C→A)
🟢 建议: 多处魔法数字需提取

## 推荐动作
1. [立即] 拆分 OrderManager (5 人天)
2. [短期] 打破循环依赖 (7 人天)
3. [中期] 补测试覆盖至 80% (10 人天)

## 风险提示
如果不对 God Class 进行处理，每新增一个功能将增加 2-3 天的修改成本。
```