跳到主要内容

依赖关系

使用 LeanSpec 的依赖跟踪管理规范之间的关系。

概述​

LeanSpec 有两种类型的关系：

related - 双向软引用​

  • 含义：信息性关系（规范是连接/相关的）
  • 行为：从两侧自动显示
  • 符号：⟷（双向箭头）

depends_on - 方向阻塞依赖​

  • 含义：硬依赖 - 在依赖完成之前规范无法开始
  • 行为：仅方向性（从每侧显示不同）
  • 符号：→（依赖于）和 ←（阻塞）

相关规范​

对信息连接使用 related：

# 在规范 042 中
related: [043, 044]

双方都看到关系：

$ lean-spec deps 042
相关规范：
  ⟷ 043-feature-launch [in-progress]
  ⟷ 044-api-update [planned]

$ lean-spec deps 043
相关规范：
  ⟷ 042-error-handling [complete]  # 自动显示！

使用时机：

  • 规范涵盖相关主题或功能
  • 工作是协调的但不阻塞
  • 上下文有帮助但不是必需的

阻塞依赖​

对硬依赖使用 depends_on：

# 规范 A 依赖于规范 B
# 在规范 A 中
depends_on: [spec-b]

从每侧显示不同：

$ lean-spec deps spec-a
依赖于：
  → spec-b [in-progress]  # A 依赖于 B

$ lean-spec deps spec-b
被需要：
  ← spec-a [planned]  # B 被 A 需要

使用时机：

  • 规范真正无法在另一个完成之前开始
  • 有明确的依赖链
  • 工作必须按特定顺序完成

Deps 命令​

查看规范的所有关系：

lean-spec deps <spec>

显示：

  • 此规范依赖的规范（→）
  • 依赖此规范的规范（←）
  • 相关规范（⟷）

示例输出​

🔗 043-feature-launch 的依赖关系

依赖于：
  → 042-error-handling [complete] ✅
  → 041-api-design [complete] ✅

被需要：
  ← 044-integration-test [planned]
  ← 045-documentation [planned]

相关规范：
  ⟷ 040-performance [in-progress]
  ⟷ 039-security-audit [complete]

状态：准备开始（所有依赖都已完成）

最佳实践​

大多数关系是信息性的，而不是阻塞的：

# ✅ 好 - 用于上下文的相关规范
related: [feature-a, feature-b]

# ❌ 过度使用 - 不是真正的阻塞依赖
depends_on: [documentation-spec]

2. 为真正的阻塞者保留 depends_on​

仅在工作真正无法开始时使用：

# ✅ 好 - API 必须在集成之前存在
depends_on: [api-implementation]

# ❌ 坏 - 这些可以并行完成
depends_on: [docs-update]

3. 避免循环依赖​

# ❌ 坏 - 循环依赖
# 规范 A
depends_on: [spec-b]

# 规范 B
depends_on: [spec-a]

LeanSpec 将警告循环依赖。

4. 更新一次，到处显示​

related 只需要在一个规范中：

# ✅ 好 - 仅在规范 A 中
# 规范 A
related: [spec-b]

# 规范 B - 无需列出 A
# （关系自动显示）

工作流程​

开始工作之前​

检查依赖：

lean-spec deps <spec>

确保在开始之前所有 depends_on 规范都已完成。

规划期间​

映射关系：

# 查看相关工作
lean-spec deps feature-spec

# 检查被阻塞的内容
lean-spec board --status planned

识别瓶颈​

找到阻塞其他规范的规范：

# 检查依赖此规范的内容
lean-spec deps <in-progress-spec>

# 查找"被需要"项目

依赖模式​

顺序工作​

# 阶段 1
status: complete

# 阶段 2
depends_on: [phase-1]
status: in-progress

# 阶段 3
depends_on: [phase-2]
status: planned

带协调的并行工作​

# 功能 A
related: [feature-b, feature-c]

# 功能 B
related: [feature-a, feature-c]

# 功能 C
related: [feature-a, feature-b]

集成点​

# 核心功能
status: in-progress

# 测试（在功能完成前被阻塞）
depends_on: [core-feature]

# 文档（可以早开始，相关）
related: [core-feature]

管理更改​

添加依赖​

# 之前
status: planned

# 之后
depends_on: [prerequisite-spec]
status: planned  # 在依赖完成之前无法开始

删除依赖​

当不再需要依赖时：

# 之前
depends_on: [old-requirement]

# 之后
# （删除 depends_on 或替换为 related）
related: [old-requirement]

提示​

  • 在开始工作之前检查依赖
  • 对大多数连接使用 related
  • 仅对真正的阻塞者使用 depends_on
  • 随着学习更新关系
  • 在规划期间审查依赖链
  • 避免长依赖链（破坏并行工作）

了解更多​