182 lines
7.1 KiB
Markdown
182 lines
7.1 KiB
Markdown
## 技术债务
|
||
|
||
分析项目的技术债务，创建按优先级排序的改进计划。
|
||
|
||
### 使用方法
|
||
|
||
```bash
|
||
# 确认项目结构并分析技术债务
|
||
ls -la
|
||
「分析这个项目的技术债务并创建改进计划」
|
||
```
|
||
|
||
### 基本示例
|
||
|
||
```bash
|
||
# 分析 TODO/FIXME 注释
|
||
grep -r "TODO\|FIXME\|HACK\|XXX\|WORKAROUND" . --exclude-dir=node_modules --exclude-dir=.git
|
||
「按优先级整理这些 TODO 注释并制定改进计划」
|
||
|
||
# 确认项目依赖关系
|
||
ls -la | grep -E "package.json|Cargo.toml|pubspec.yaml|go.mod|requirements.txt"
|
||
「分析项目的依赖关系，识别过时的依赖和风险」
|
||
|
||
# 检测大文件和复杂函数
|
||
find . -type f -not -path "*/\.*" -not -path "*/node_modules/*" -exec wc -l {} + | sort -rn | head -10
|
||
「识别过大的文件和复杂的结构，提出改进方案」
|
||
```
|
||
|
||
### 与 Claude 配合
|
||
|
||
```bash
|
||
# 全面的技术债务分析
|
||
ls -la && find . -name "*.md" -maxdepth 2 -exec head -20 {} \;
|
||
「从以下角度分析这个项目的技术债务：
|
||
1. 代码质量 (复杂度、重复、可维护性)
|
||
2. 依赖关系健康度
|
||
3. 安全风险
|
||
4. 性能问题
|
||
5. 测试覆盖不足」
|
||
|
||
# 架构债务分析
|
||
find . -type d -name "src" -o -name "lib" -o -name "app" | head -10 | xargs ls -la
|
||
「识别架构层面的技术债务，提出重构计划」
|
||
|
||
# 按优先级排序的改进计划
|
||
「按以下标准评估技术债务并以表格形式展示：
|
||
- 影响度 (高/中/低)
|
||
- 修复成本 (时间)
|
||
- 业务风险
|
||
- 改进效果
|
||
- 推荐实施时期」
|
||
```
|
||
|
||
### 详细示例
|
||
|
||
```bash
|
||
# 自动检测项目类型并分析
|
||
find . -maxdepth 2 -type f \( -name "package.json" -o -name "Cargo.toml" -o -name "pubspec.yaml" -o -name "go.mod" -o -name "pom.xml" \)
|
||
「基于检测到的项目类型，分析以下内容：
|
||
1. 语言和框架特定的技术债务
|
||
2. 偏离最佳实践的情况
|
||
3. 现代化机会
|
||
4. 分阶段改进策略」
|
||
|
||
# 代码质量指标分析
|
||
find . -type f -name "*" | grep -E "\.(js|ts|py|rs|go|dart|kotlin|swift|java)$" | wc -l
|
||
「分析项目的代码质量，展示以下指标：
|
||
- 循环复杂度高的函数
|
||
- 重复代码检测
|
||
- 过长的文件/函数
|
||
- 缺乏适当的错误处理」
|
||
|
||
# 安全债务检测
|
||
grep -r "password\|secret\|key\|token" . --exclude-dir=.git --exclude-dir=node_modules | grep -v ".env.example"
|
||
「检测安全相关的技术债务，提出修复优先级和对策」
|
||
|
||
# 测试不足分析
|
||
find . -type f \( -name "*test*" -o -name "*spec*" \) | wc -l && find . -type f -name "*.md" | xargs grep -l "test"
|
||
「分析测试覆盖的技术债务，提出测试策略」
|
||
```
|
||
|
||
### 项目健康度仪表盘
|
||
|
||
```text
|
||
项目健康度评分：72/100
|
||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||
|
||
📊 分类评分
|
||
├─ 依赖关系新鲜度：████████░░ 82%(最新：45/55)
|
||
├─ 文档完整度：███░░░░░░░ 35%(缺少 README、API 文档)
|
||
├─ 测试覆盖率：██████░░░░ 65%(目标：80%)
|
||
├─ 安全性：███████░░░ 78%(漏洞：2 个中等风险)
|
||
├─ 架构：██████░░░░ 60%(循环依赖：3 处)
|
||
└─ 代码质量：███████░░░ 70%(高复杂度：12 个文件)
|
||
|
||
📈 趋势 (过去 30 天)
|
||
├─ 总体评分：68 → 72 (+4) ↗️
|
||
├─ 改进项目：12 项 ✅
|
||
├─ 新增债务：3 项 ⚠️
|
||
├─ 已解决债务：8 项 🎉
|
||
└─ 改进速度：+0.13/天
|
||
|
||
⏱️ 债务的时间影响
|
||
├─ 开发速度降低：-20%(新功能开发需要正常 1.25 倍时间)
|
||
├─ Bug 修复时间增加：+15%(平均修复时间 2h → 2.3h)
|
||
├─ 代码审查开销：+30%(复杂度导致理解时间增加)
|
||
├─ 入职延迟：+50%(新成员理解所需时间)
|
||
└─ 累积延迟时间：相当于每周 40 小时
|
||
|
||
🎯 改进预期效果 (基于时间)
|
||
├─ 即时效果：开发速度 +10%(1 周后)
|
||
├─ 短期效果：Bug 率 -25%(1 个月后)
|
||
├─ 中期效果：开发速度 +30%(3 个月后)
|
||
├─ 长期效果：维护时间 -50%(6 个月后)
|
||
└─ ROI：投资 40 小时 → 回收 120 小时 (3 个月)
|
||
```
|
||
|
||
### 优先级矩阵
|
||
|
||
| 优先级 | 开发影响 | 修复成本 | 时间节省效果 | 投资效率 | 响应期限 |
|
||
| ----------------- | -------- | -------- | ------------ | ------------------- | -------- |
|
||
| **[P0] 立即修复** | 高 | 低 | > 5 倍 | 投资 1h → 节省 5h+ | 立即 |
|
||
| **[P1] 本周内** | 高 | 中 | 2-5 倍 | 投资 1h → 节省 2-5h | 1 周内 |
|
||
| **[P2] 本月内** | 低 | 高 | 1-2 倍 | 投资 1h → 节省 1-2h | 1 个月内 |
|
||
| **[P3] 本季度内** | 低 | 低 | < 1 倍 | 投资=节省时间 | 3 个月内 |
|
||
|
||
### 债务类型评估标准
|
||
|
||
| 债务类型 | 检测方法 | 开发影响 | 修复时间 |
|
||
| ---------------- | --------------------- | ------------------------ | -------- |
|
||
| **架构债务** | 循环依赖、紧耦合 | 变更影响范围大、测试困难 | 40-80h |
|
||
| **安全债务** | CVE 扫描、OWASP | 漏洞风险、合规问题 | 8-40h |
|
||
| **性能债务** | N+1 查询、内存泄漏 | 响应时间增加、资源消耗 | 16-40h |
|
||
| **测试债务** | 覆盖率 < 60% | Bug 检测延迟、质量不稳定 | 20-60h |
|
||
| **文档债务** | 缺少 README、API 文档 | 入职时间增加 | 8-24h |
|
||
| **依赖债务** | 2 年以上未更新 | 安全风险、兼容性问题 | 4-16h |
|
||
| **代码质量债务** | 复杂度 > 10 | 理解/修改时间增加 | 2-8h |
|
||
|
||
### 技术债务影响度计算
|
||
|
||
```text
|
||
影响度 = Σ(各要素权重 × 测量值)
|
||
|
||
📊 可测量的影响指标：
|
||
├─ 开发速度影响
|
||
│ ├─ 代码理解时间：+X%(与复杂度成正比)
|
||
│ ├─ 变更时影响范围：Y 个文件 (通过耦合度测量)
|
||
│ └─ 测试执行时间：Z 分钟 (CI/CD 流水线)
|
||
│
|
||
├─ 质量影响
|
||
│ ├─ Bug 发生率：复杂度每 10 分增加 +25%
|
||
│ ├─ 代码审查时间：代码行数 × 复杂度系数
|
||
│ └─ 测试不足风险：覆盖率 < 60% 时高风险
|
||
│
|
||
└─ 团队效率影响
|
||
├─ 入职时间：缺少文档时增加 +100%
|
||
├─ 知识孤岛：单一贡献者比例 >80% 时需要注意
|
||
└─ 代码重复修复位置：重复率 × 变更频率
|
||
```
|
||
|
||
### 基于时间的 ROI 计算
|
||
|
||
```text
|
||
ROI = (节省时间 - 投资时间) ÷ 投资时间 × 100
|
||
|
||
示例：解决循环依赖
|
||
├─ 投资时间：16 小时 (重构)
|
||
├─ 每月节省：
|
||
│ ├─ 编译时间：-10 分钟/天 × 20 天 = 200 分钟
|
||
│ ├─ 调试时间：-2 小时/周 × 4 周 = 8 小时
|
||
│ └─ 新功能开发：-30% 时间缩短 = 12 小时
|
||
├─ 每月节省时间：23.3 小时
|
||
└─ 3 个月 ROI：(70 - 16) ÷ 16 × 100 = 337%
|
||
```
|
||
|
||
### 注意事项
|
||
|
||
- 自动检测项目的语言和框架，进行相应的分析
|
||
- 健康度评分采用 0-100 分制：70 分以上健康，50 分以下需要改进
|
||
- 计算具体的时间成本和改进效果，支持基于数据的决策制定
|
||
- 如需货币换算，请单独指定团队平均时薪或项目特定系数
|