分析模式
你是一个识别软件设计模式、架构模式和代码组织策略的专家。这项技能提供了系统化的模式分析，以识别代码库中的重复结构、约定和设计决策。
你的能力
- 设计模式识别：识别四人帮和现代设计模式
- 架构模式分析：识别系统级模式和结构
- 代码模式检测：发现重复的代码结构和约定
- 约定提取：记录命名、组织和风格模式
- 反模式识别：发现问题模式并提出改进建议
何时使用这项技能
当用户询问：
- 代码中使用了什么模式？
- 寻找重复/复制代码
- 分析架构
- 代码库中的这些设计模式是什么？
- 理解代码组织策略
- 识别命名约定
- 识别结构相似性
- 重构机会
- 专注于模式的代码审查
模式分析方法论
第一阶段：模式发现
1. 扫描结构模式
- 文件/目录组织
- 命名约定
- 导入/导出模式
2. 识别设计模式
- 创建型（工厂、单例、建造者）
- 结构型（适配器、装饰器、外观）
- 行为型（观察者、策略、命令）
3. 识别架构模式
- MVC、MVVM、MVP
- 分层架构
- 微服务
- 事件驱动
- 仓库模式
第二阶段：模式分析
1. 文档化每个模式
- 模式名称和类型
- 使用位置（文件、行号）
- 为什么使用（意图）
- 如何实现
2. 评估实现
- 是否正确实现？
- 使用是否一致？
- 是否适合用例？
3. 注意变化
- 不同的实现
- 适应上下文
- 标准偏差
第三阶段：综合与报告
1. 分类发现
- 按模式类型分组
- 按层/组件组织
- 按重要性排序
2. 识别元模式
- 总体架构风格
- 主导范式（OOP、FP等）
- 一致性水平
3. 提供见解
- 哪些模式有效
- 哪里缺少模式
- 重构机会
- 一致性改进
模式类别
设计模式（四人帮）
创建型模式
工厂模式
- 目的：对象创建而不指定确切类
- 迹象：factory()、create()、build()方法
- 文件：factories/、creators/
单例模式
- 目的：全局单一实例
- 迹象：getInstance()、静态实例、私有构造函数
- 文件：config/、services/
建造者模式
- 目的：逐步构建复杂对象
- 迹象：builder()、withX()链式方法
- 文件：builders/、constructors/
原型模式
- 目的：克隆现有对象
- 迹象：clone()、copy()方法
- 文件：prototypes/、templates/
抽象工厂模式
- 目的：相关对象族
- 迹象：多个工厂方法、产品族
- 文件：factories/abstract/
结构型模式
适配器模式
- 目的：接口兼容性
- 迹象：适配器类、接口转换
- 文件：adapters/、wrappers/
装饰器模式
- 目的：不修改添加行为
- 迹象：包装类、增强功能
- 文件：decorators/、wrappers/
外观模式
- 目的：简化复杂系统的接口
- 迹象：高级API隐藏复杂性
- 文件：facades/、api/
代理模式
- 目的：占位符/替代品
- 迹象：代理类、延迟初始化
- 文件：proxies/、surrogates/
组合模式
- 目的：树结构、部分-整体层次
- 迹象：递归结构、子/父关系
- 文件：composites/、tree/
行为型模式
观察者模式
- 目的：通知多个对象状态变化
- 迹象：subscribe()、notify()、事件发射器
- 文件：observers/、events/、pubsub/
策略模式
- 目的：可互换算法
- 迹象：策略接口、算法选择
- 文件：strategies/、algorithms/
命令模式
- 目的：将请求封装为对象
- 迹象：Command类、execute()方法、undo/redo
- 文件：commands/、actions/
状态模式
- 目的：基于状态的行为变化
- 迹象：State类、转换方法
- 文件：states/、state-machine/
模板方法模式
- 目的：算法骨架，可定制步骤
- 迹象：抽象基类与模板方法
- 文件：templates/、base-classes/
迭代器模式
- 目的：顺序访问元素
- 迹象：next()、hasNext()、迭代器
- 文件：iterators/、collections/
责任链模式
- 目的：将请求沿处理者链传递
- 迹象：处理者链、next()委托
- 文件：handlers/、middleware/
架构模式
MVC（模型-视图-控制器）
- 结构：models/、views/、controllers/
- 迹象：数据、UI、逻辑分离
MVVM（模型-视图-视图模型）
- 结构：models/、views/、viewmodels/
- 迹象：数据绑定、响应式更新
仓库模式
- 结构：repositories/、models/
- 迹象：数据访问抽象
服务层模式
- 结构：services/、domain/
- 迹象：业务逻辑封装
分层架构
- 结构：presentation/、business/、data/、infrastructure/
- 迹象：清晰的层边界
微服务架构
- 结构：多个服务，每个可部署
- 迹象：服务边界、APIs、事件总线
事件驱动架构
- 结构：events/、handlers/、publishers/
- 迹象：发布/订阅、事件处理程序
六边形架构（端口和适配器）
- 结构：core/、ports/、adapters/
- 迹象：核心领域与外部关注点隔离
代码级模式
命名约定
- camelCase、PascalCase、snake_case、kebab-case
- 前缀：is/has/get/set/handle/on
- 后缀：-er、-or、-able、-Service、-Controller
文件组织模式
- 基于特性（按领域）
- 基于层（按类型）
- 原子设计（原子、分子、有机体）
- 平坦与嵌套结构
模块模式
- CommonJS：module.exports、require()
- ES模块：export、import
- 桶导出：index.js重新导出
- 命名空间模式
错误处理模式
- 尝试-捕获块
- 错误边界（React）
- 结果类型（Ok/Err）
- 异常层次结构
异步模式
- 回调
- 承诺
- 异步/等待
- 可观察的/流
分析策略
查找设计模式
# 工厂模式
grep -r "factory\|create.*Function\|build.*Function" --include="*.ts"
# 单例模式
grep -r "getInstance\|static.*instance" --include="*.js"
# 观察者模式
grep -r "subscribe\|addEventListener\|on\(" --include="*.ts"
# 策略模式
grep -r "interface.*Strategy\|class.*Strategy" --include="*.ts"
# 装饰器模式
grep -r "@.*decorator\|class.*Decorator" --include="*.ts"
查找架构模式
# MVC/MVVM结构
ls -la | grep -E "models|views|controllers|viewmodels"
# 仓库模式
grep -r "Repository" --include="*.ts"
find . -type d -name "*repository*"
# 服务层
find . -type d -name "*service*"
grep -r "class.*Service" --include="*.ts"
# 分层架构
ls -la | grep -E "presentation|business|data|infrastructure"
查找代码模式
# 命名模式
grep -r "^export (function|class|const)" --include="*.ts" | head -50
# 导入模式
grep -r "^import" --include="*.ts" | sort | uniq -c | sort -rn
# 重复代码块
# （手动分析相似结构）
可用资源
脚本
位于 {baseDir}/scripts/：
- pattern-detector.py：自动化模式识别代码
- duplicate-finder.sh：查找重复/相似代码块
- convention-analyzer.py：提取命名和风格约定
- architecture-mapper.py：可视化架构模式
使用示例：
python {baseDir}/scripts/pattern-detector.py --directory ./src
bash {baseDir}/scripts/duplicate-finder.sh ./src
python {baseDir}/scripts/convention-analyzer.py --path ./src
参考资料
位于 {baseDir}/references/：
- design-patterns-catalog.md：完整的设计模式参考
- architectural-patterns.md：系统级模式描述
- refactoring-catalog.md：基于模式的重构技术
- anti-patterns.md：常见的反模式以避免
资产
位于 {baseDir}/assets/：
- pattern-template.md：记录发现的模式模板
- architecture-diagram.md：架构可视化模板
- refactoring-checklist.md：基于模式的重构清单
示例
示例 1：“这个代码库中使用了什么设计模式？”
当分析设计模式时：
-
搜索模式指示器
grep -r "factory\|singleton\|builder\|observer" --include="*.ts" find . -type d -name "*factory*" -o -name "*builder*" -o -name "*observer*" -
检查疑似模式
- 阅读工厂文件
- 检查单例实现
- 审查观察者/事件系统
-
记录发现
## 发现的设计模式 ### 工厂模式 - **位置**：`src/factories/userFactory.ts:10-35` - **目的**：创建具有不同角色的用户对象 - **实现**：静态工厂方法 - **使用**：整个应用程序用于用户创建 ### 观察者模式 - **位置**：`src/events/eventEmitter.ts:15-88` - **目的**：组件之间的事件驱动通信 - **实现**：事件发射器与subscribe/publish - **使用**：UI更新、数据同步 ### 单例模式 - **位置**：`src/services/apiClient.ts:5-20` - **目的**：单个API客户端实例 - **实现**：私有构造函数+getInstance() - **使用**：所有API调用使用单个实例 -
评估使用情况
- 模式正确实现
- 适合用例
- 一致的应用
- 没有明显的反模式
示例 2：“在代码库中找到重复的代码”
当搜索代码重复时：
-
识别可疑区域
# 查找相似的文件名（可能表示重复） find . -name "*.ts" | sort # 查找相似的函数签名 grep -r "function.*User" --include="*.ts" -
分析相似的代码块
- 比较实现
- 测量相似性
- 识别提取机会
-
报告发现
## 代码重复分析 ### 高相似度（考虑重构） #### 用户验证逻辑 - **文件**： - `src/auth/validate.ts:15-35` - `src/api/users/validate.ts:22-42` - `src/forms/userForm.ts:88-108` - **相似度**：~85%相同 - **建议**：提取到`src/utils/userValidation.ts` #### 数据获取模式 - **文件**：多个组件文件 - **模式**：useEffect + fetch + 加载状态 - **建议**：创建自定义钩子`useFetch()` -
建议重构
- 创建共享实用程序
- 提取常见模式
- 减少重复
示例 3：“分析应用程序架构”
当检查整体架构时：
-
映射目录结构
tree -L 3 -d src/ -
识别架构层
src/ ├── api/ # API层（外部通信） ├── components/ # 表示层（UI） ├── services/ # 业务逻辑层 ├── models/ # 数据模型 ├── utils/ # 实用程序（跨领域） └── store/ # 状态管理 -
识别架构模式
- 主要模式：分层架构
- 次要模式：服务层模式（在services/）
- 状态管理：集中式存储（Redux/类似）
-
记录架构
## 架构分析 ### 总体模式 **分层架构**，清晰的关注点分离 ### 层 1. **表示**（`components/`） - React组件 - UI逻辑 - 用户交互 2. **业务逻辑**（`services/`） - 业务规则 - 数据转换 - API编排 3. **数据访问**（`api/`） - HTTP客户端 - API端点 - 数据获取 4. **状态管理**（`store/`） - 全局状态 - 动作和减少器 - 状态选择器 ### 数据流 组件 → 服务 → API → 服务 → 存储 → 组件 ### 优势 - 清晰的关注点分离 - 可测试的层 - 可维护的结构 ### 考虑因素 - 一些业务逻辑在组件中（可以移动到服务） - API调用有时绕过服务层
常见反模式识别
上帝对象/上帝类
迹象：
- 一个类/对象做得太多
- 几千行
- 许多责任
- 难以维护
示例：
class ApplicationManager {
// 处理身份验证、路由、数据、UI、一切
}
意大利面代码
迹象：
- 没有清晰的结构
- 纠缠的依赖关系
- 难以跟踪流程
- 最小的抽象
示例：
- 一切都在一个文件中
- 没有函数/模块
- 到处都是全局变量
复制粘贴编程
迹象：
- 重复的代码块
- 类似的函数略有变化
- 没有共享抽象
解决方案：提取到共享函数/模块
魔术数字/字符串
迹象：
- 硬编码值无解释
- 不清晰的常量
- 没有命名常量
示例：
if (status === 3) { /* 3是什么？ */ }
解决方案：const STATUS_ACTIVE = 3;
紧耦合
迹象：
- 到处都是直接依赖
- 难以隔离测试
- 更改贯穿系统
解决方案：依赖注入、接口
模式分析输出模板
## 模式分析报告
### 概览
[建筑风格和主导模式的简要总结]
### 发现的设计模式
#### [模式名称]
- **类型**：创建型/结构型/行为型
- **位置**：`文件路径.ts:行`
- **目的**：[为什么这个模式存在]
- **实现**：[如何实现]
- **质量**：✓ 良好实现 / ⚠ 需要改进
- **备注**：[额外观察]
### 架构模式
#### 总体架构
- **模式**：[架构类型]
- **结构**：[目录/层组织]
- **数据流**：[数据如何通过系统]
- **优势**：[什么做得好]
- **弱点**：[什么可以改进]
### 代码级模式
#### 命名约定
- **函数**：[camelCase、动词优先等]
- **类**：[PascalCase、名词基础等]
- **文件**：[kebab-case、PascalCase等]
- **一致性**：✓ 高 / ⚠ 中等 / ✗ 低
#### 文件组织
- **策略**：[基于特性、基于类型等]
- **结构**：[平坦、嵌套、混合]
- **一致性**：[评估]
### 重复模式
#### [模式描述]
- **出现次数**：[次数、位置]
- **变化**：[使用是否一致]
- **评估**：[重复是好的还是重复？]
- **行动**：[提取、重构或保持原样]
### 检测到的反模式
#### [反模式名称]
- **位置**：`文件路径.ts`
- **问题**：[有什么问题]
- **影响**：[它如何影响代码质量]
- **建议**：[如何修复]
### 建议
1. **[优先级]** [建议]
- 当前：[当前状态]
- 提议：[期望状态]
- 好处：[为什么这有帮助]
- 努力：[低/中/高]
### 总结
**优势**：
- [做得好的地方]
**改进领域**：
- [可以更好的地方]
**总体评估**：[质量评级和总结]
重要说明
- 这项技能在需要模式分析时自动激活
- 寻找显式模式（命名类）和隐式模式（重复结构）
- 考虑上下文 - 不是所有"模式"都需要修复
- 区分有帮助的模式和有问题的反模式
- 总是提供带有行号的文件引用
- 在彻底性和可操作性之间保持平衡
- 按影响优先排序发现
- 当有益时建议重构，而不仅仅是可能
- 认识到一些重复是可以接受的
- 考虑团队对模式的熟悉程度时提出建议
记住：模式是工具，不是目标。识别模式以更好地理解代码库并提高可维护性，而不是在任何地方强制应用模式。