parallel-feature-development

并行功能开发

将功能分解为并行工作流、建立文件所有权边界、避免冲突，以及整合多个实现者 Agent 的成果的策略。

何时使用本技能

• 将功能分解以进行并行实现
• 在 Agent 之间建立文件所有权边界
• 设计并行工作流之间的接口契约
• 选择集成策略（垂直切片 vs 水平分层）
• 管理并行开发的分支与合并工作流

文件所有权策略

按目录

为每个实现者分配特定目录的所有权：

implementer-1: src/components/auth/
implementer-2: src/api/auth/
implementer-3: tests/auth/

最适合：目录边界清晰、组织良好的代码库。

按模块

分配逻辑模块的所有权（模块可能跨越多个目录）：

implementer-1: Authentication module (login, register, logout)
implementer-2: Authorization module (roles, permissions, guards)

最适合：面向功能的架构、领域驱动设计。

按分层

分配架构层的所有权：

implementer-1: UI layer (components, styles, layouts)
implementer-2: Business logic layer (services, validators)
implementer-3: Data layer (models, repositories, migrations)

最适合：传统的 MVC／分层架构。

冲突避免规则

基本规则

每个文件只有一个所有者。 任何文件都不应分配给多个实现者。

当文件必须共享时

如果某个文件确实需要多个实现者修改：

1. 指定唯一所有者 —— 一个实现者拥有该文件
2. 其他实现者提出修改请求 —— 向所有者发送具体的修改请求
3. 所有者按顺序应用修改 —— 避免合并冲突
4. 替代方案：抽取接口 —— 创建一个单独的接口文件，非所有者可以导入而无需修改原文件

接口契约

当实现者需要在边界处协调时：

// src/types/auth-contract.ts (owned by team-lead, read-only for implementers)
export interface AuthResponse {
  token: string;
  user: UserProfile;
  expiresAt: number;
}

export interface AuthService {
  login(email: string, password: string): Promise<AuthResponse>;
  register(data: RegisterData): Promise<AuthResponse>;
}

两个实现者都从契约文件导入，但都不修改它。

集成模式

垂直切片

每个实现者构建一个完整的功能切片（UI + API + 测试）：

implementer-1: Login feature (login form + login API + login tests)
implementer-2: Register feature (register form + register API + register tests)

优点：每个切片可独立测试，集成需求最少。 缺点：可能重复实现共享工具，对紧耦合功能较难适用。

水平分层

每个实现者跨所有功能构建一个层：

implementer-1: All UI components (login form, register form, profile page)
implementer-2: All API endpoints (login, register, profile)
implementer-3: All tests (unit, integration, e2e)

优点：每一层内模式一致，天然便于专业化。 缺点：集成点更多，第 3 层依赖第 1 层和第 2 层。

混合

根据耦合程度混合使用垂直和水平方式：

implementer-1: Login feature (vertical slice — UI + API + tests)
implementer-2: Shared auth infrastructure (horizontal — middleware, JWT utils, types)

最适合：大多数带有部分共享基础设施的真实功能。

分支管理

单分支策略

所有实现者在同一个功能分支上工作：

• 设置简单，无合并开销
• 需要严格的文件所有权以避免冲突
• 最适合：小型团队（2-3 人）、边界明确的情况

多分支策略

每个实现者在各自的子分支上工作：

feature/auth
  ├── feature/auth-login      (implementer-1)
  ├── feature/auth-register    (implementer-2)
  └── feature/auth-tests       (implementer-3)

• 隔离性更强，有明确的合并点
• 开销更高，共享文件中仍可能出现合并冲突
• 最适合：较大团队（4 人以上）、复杂功能

故障排查

实现者互相阻塞，都在等待共享代码。 把共享部分提取到独立的接口契约文件中，由 team-lead 负责维护，让实现者从该文件导入。两个实现者都不修改契约——他们只针对契约进行实现。

即使有明确的所有权规则，仍然出现合并冲突。 某个文件被分配给了两个 Agent，或者某个会自动导入所有内容的配置/索引文件（例如 index.ts、__init__.py）被双方修改了。为所有 barrel/index 文件指定唯一所有者，或让 lead 在最后统一合并它们。

某个实现者提前完成，但集成步骤被阻塞。 使用暂存接口：已完成的实现者为下游依赖编写一个桩或 mock，以便另一个实现者可以继续工作。在集成时替换为真实实现。

功能拆分在中途被发现是错的。 停止新工作，让 lead 重新分配文件，并通过广播传达这一变更。部分已写代码的沉没成本是可以接受的——继续按错误拆分推进更糟。

某个实现者编写的测试在另一个实现者编写的代码上失败。 接口契约发生了偏移：拥有 API 的实现者在未通知测试实现者的情况下更改了签名。强制执行这条规则：修改契约文件前必须广播。

相关技能

• team-composition-patterns — 在拆分工作前选择合适的团队规模和 Agent 类型
• team-communication-protocols — 在实现者之间协调集成交接和计划审批