parallel-feature-development

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Parallel Feature Development

并行功能开发

Strategies for decomposing features into parallel work streams, establishing file ownership boundaries, avoiding conflicts, and integrating results from multiple implementer agents.

本文介绍如何通过文件所有权策略、冲突规避规则和集成模式，协调多Agent实现的并行功能开发。

When to Use This Skill

何时使用此技能

Decomposing a feature for parallel implementation
Establishing file ownership boundaries between agents
Designing interface contracts between parallel work streams
Choosing integration strategies (vertical slice vs horizontal layer)
Managing branch and merge workflows for parallel development

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

File Ownership Strategies

文件所有权策略

By Directory

按目录划分

Assign each implementer ownership of specific directories:

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

Best for: Well-organized codebases with clear directory boundaries.

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

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

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

By Module

按模块划分

Assign ownership of logical modules (which may span directories):

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

Best for: Feature-oriented architectures, domain-driven design.

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

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

最适用于：面向特性的架构、领域驱动设计。

By Layer

按分层划分

Assign ownership of architectural layers:

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

Best for: Traditional MVC/layered architectures.

为架构分层分配所有权：

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

最适用于：传统MVC/分层架构。

Conflict Avoidance Rules

冲突规避规则

The Cardinal Rule

核心规则

One owner per file. No file should be assigned to multiple implementers.

每个文件仅归属一个所有者。不得将单个文件分配给多个实现者。

When Files Must Be Shared

必须共享文件时的处理方式

If a file genuinely needs changes from multiple implementers:

Designate a single owner — One implementer owns the file
Other implementers request changes — Message the owner with specific change requests
Owner applies changes sequentially — Prevents merge conflicts
Alternative: Extract interfaces — Create a separate interface file that the non-owner can import without modifying

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

指定单一所有者 — 由一名实现者拥有该文件
其他实现者提交变更请求 — 向所有者发送具体的变更请求
所有者按顺序应用变更 — 避免合并冲突
替代方案：提取接口 — 创建独立的接口文件，非所有者可导入但不可修改

Interface Contracts

接口契约

When implementers need to coordinate at boundaries:

typescript

// 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>;
}

Both implementers import from the contract file but neither modifies it.

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

typescript

// 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>;
}

所有实现者均可从契约文件导入内容，但不得修改该文件。

Integration Patterns

集成模式

Vertical Slice

垂直切片

Each implementer builds a complete feature slice (UI + API + tests):

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

Pros: Each slice is independently testable, minimal integration needed. Cons: May duplicate shared utilities, harder with tightly coupled features.

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

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

优点：每个切片可独立测试，所需集成工作最少。缺点：可能重复共享工具，在强耦合特性中难度较高。

Horizontal Layer

水平分层

Each implementer builds one layer across all features:

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)

Pros: Consistent patterns within each layer, natural specialization. Cons: More integration points, layer 3 depends on layers 1 and 2.

每个实现者构建覆盖所有特性的单个分层：

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)

优点：每个分层内模式一致，自然形成专业化分工。缺点：集成点更多，第三层依赖于第一层和第二层。

Hybrid

混合模式

Mix vertical and horizontal based on coupling:

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

Best for: Most real-world features with some shared infrastructure.

根据耦合程度结合垂直和水平模式：

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

最适用于：大多数包含共享基础设施的实际特性。

Branch Management

分支管理

Single Branch Strategy

单分支策略

All implementers work on the same feature branch:

Simple setup, no merge overhead
Requires strict file ownership to avoid conflicts
Best for: small teams (2-3), well-defined boundaries

所有实现者在同一个特性分支上工作：

设置简单，无合并开销
需要严格的文件所有权以避免冲突
最适用于：小型团队（2-3人）、边界清晰的场景

Multi-Branch Strategy

多分支策略

Each implementer works on a sub-branch:

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

More isolation, explicit merge points
Higher overhead, merge conflicts still possible in shared files
Best for: larger teams (4+), complex features

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

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

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