SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsdependency-map

dependency-map

Coding & development

View repository

Updated 10-15 10:19

About this skill

Dependency Map

The scariest part of a code change is not making a mistake, but not knowing where the change reaches. The mission of this skill: before making a change, draw a map of the impact scope.

Step 1: Determine the analysis target

Use AskUserQuestion to confirm:

  • What to analyze: which function/class/module/file?
  • Why analyze: what are you preparing to change? Delete? Or purely to understand?
  • Analysis depth: only look at direct dependencies, or trace all the way down?
分析请求
  │
  ├─ 改函数签名 → 追踪所有调用方
  ├─ 改数据结构 → 追踪数据的读写点
  ├─ 删文件/模块 → 追踪所有 import
  ├─ 改 API 接口 → 追踪前端调用 + 外部消费方
  └─ 改配置/环境变量 → 追踪所有引用点

Step 2: Static dependency analysis

2.1 Import/Require analysis

# 找到谁引用了目标文件
grep -r "import.*from.*'目标模块'" src/
grep -r "require('目标模块')" src/

# 或用 Grep 工具搜索

Output format:

## 引用关系

### 被谁引用（上游，改目标会影响他们）
- `src/api/auth.ts:3` — import { login } from './services/auth'
- `src/api/user.ts:5` — import { validateToken } from './services/auth'
- `tests/auth.test.ts:1` — import { login, logout } from '../services/auth'

### 引用了谁（下游，目标依赖他们）
- `src/models/user.ts` — UserModel
- `src/utils/jwt.ts` — signToken, verifyToken
- `bcrypt` — 外部依赖

2.2 Function/method-level call chains

For function-level analysis, trace finer-grained call relationships:

# 搜索函数名的所有调用
grep -rn "目标函数名(" src/ --include="*.ts" --include="*.js"

Output format:

## 调用链：validateToken()

定义：src/services/auth.ts:45

调用方：
├─ src/middleware/auth.ts:12 — authMiddleware() 每个请求都会调用
│   └─ 被 src/api/index.ts:8 的 app.use(authMiddleware) 注册为全局中间件
├─ src/api/user.ts:23 — getUserProfile() 手动调用做额外校验
└─ tests/auth.test.ts:34 — 测试用例

影响面评估：
- authMiddleware 是全局中间件 → 改签名会影响所有需要认证的接口
- 测试需要同步更新

Step 3: Data flow analysis

When a change involves data structures, trace where the data comes from and where it goes:

3.1 Data structure changes

## 数据流：User 类型

### 定义位置
`src/types/user.ts:5` — interface User { id, name, email, role }

### 创建点（写入）
- `src/services/user.ts:createUser()` — 注册时创建
- `src/services/auth.ts:oauthCallback()` — OAuth 登录时创建

### 读取点
- `src/api/user.ts:getUserProfile()` — 返回给前端
- `src/middleware/auth.ts:12` — 从 token 解析出 user
- `src/services/order.ts:45` — 创建订单时读取 user.id

### 持久化
- `src/models/user.ts` — 数据库 users 表
- `src/utils/cache.ts:getUserCache()` — Redis 缓存

### 影响评估
如果给 User 加字段：
- 数据库需要 migration
- 缓存的序列化/反序列化需要兼容
- API 响应自动包含（如果没有字段过滤的话）

如果删 User 字段：
- 检查所有读取点是否还在用
- 前端是否依赖这个字段

Step 4: Output impact scope assessment

4.1 Impact scope checklist

## 影响面评估：<改动描述>

### 直接影响（必须改）
| 文件 | 行号 | 影响原因 | 改动类型 |
|------|------|---------|---------|
| src/api/auth.ts | 23 | 调用了要修改的函数 | 同步更新参数 |
| src/middleware/auth.ts | 12 | 依赖返回值结构 | 适配新结构 |

### 间接影响（需要验证）
| 文件 | 行号 | 风险点 | 验证方式 |
|------|------|--------|---------|
| src/api/user.ts | 45 | 使用了相同的类型 | 跑测试确认 |

### 不受影响（确认安全）
- src/services/order.ts — 虽然在同目录，但无依赖关系
- src/utils/format.ts — 纯工具函数，不涉及

### 测试影响
- tests/auth.test.ts — 需要更新测试用例
- tests/user.test.ts — 需要回归验证

4.2 Risk level

Level Criteria
Low risk Only affects internal implementation, public interfaces unchanged, test coverage exists
Medium risk Affects multiple files but does not affect external interfaces, partial test coverage exists
High risk Affects public interfaces/global middleware/data structures, insufficient test coverage

Analysis guidelines

  • Better to include too much than to miss: put uncertain items under "needs verification," not under "not affected"
  • Annotate line numbers: every impact point must be annotated with its specific location for easy locating
  • Distinguish direct/indirect: direct impacts must be changed, indirect impacts need verification; do not mix them together
  • Watch for implicit dependencies: don't just look at imports; also look at runtime dependencies (event listeners, global state, environment variables)
  • Recursive but bounded: tracing call chains must have a depth limit; generally 3 levels is enough. Indirect impacts beyond 3 levels can be ignored

Relationship with other skills

code-walkthrough（理解代码）→ dependency-map（评估影响）→ refactoring（执行改动）

dependency-map vs code-walkthrough：

  • walkthrough：Understandthe code. "What is this code, how does it operate"
  • dependency-map：Assessimpact. "What will changing this touch"
  • Usually first do a walkthrough to build understanding, then dependency-map to assess the change