incremental-implementation

Incremental Implementation

概览

用薄的垂直切片构建：实现一小块，测试它，验证它，然后再扩展。避免一次性实现整个功能。每个增量都应该让系统保持可工作、可测试的状态。这是让大型功能可管理的执行纪律。

何时使用

• 实现任何多文件变更
• 从任务拆解中构建新功能
• 重构现有代码
• 任何你想在测试前写超过约 100 行代码的时候

何时不要使用： 范围已经最小化的单文件、单函数变更。

增量循环

┌──────────────────────────────────────┐
│                                      │
│   Implement ──→ Test ──→ Verify ──┐  │
│       ▲                           │  │
│       └───── Commit ◄─────────────┘  │
│              │                       │
│              ▼                       │
│          Next slice                  │
│                                      │
└──────────────────────────────────────┘

对每个切片：

1. Implement 最小的完整功能片段
2. Test：运行测试套件（或在没有测试时编写测试）
3. Verify：确认切片按预期工作（测试通过、构建成功、手动检查）
4. Commit：用描述性消息保存进度（原子提交指导见 git-workflow-and-versioning）
5. Move to the next slice：继续推进，不要从头开始

切片策略

垂直切片（优先）

构建一条贯穿整个技术栈的完整路径：

Slice 1: Create a task (DB + API + basic UI)
    → Tests pass, user can create a task via the UI

Slice 2: List tasks (query + API + UI)
    → Tests pass, user can see their tasks

Slice 3: Edit a task (update + API + UI)
    → Tests pass, user can modify tasks

Slice 4: Delete a task (delete + API + UI + confirmation)
    → Tests pass, full CRUD complete

每个切片都交付可工作的端到端功能。

Contract-First Slicing

当后端和前端需要并行开发时：

Slice 0: Define the API contract (types, interfaces, OpenAPI spec)
Slice 1a: Implement backend against the contract + API tests
Slice 1b: Implement frontend against mock data matching the contract
Slice 2: Integrate and test end-to-end

Risk-First Slicing

先处理风险最高或最不确定的部分：

Slice 1: Prove the WebSocket connection works (highest risk)
Slice 2: Build real-time task updates on the proven connection
Slice 3: Add offline support and reconnection

如果 Slice 1 失败，你会在投入 Slice 2 和 3 前发现。

实现规则

规则 0：简单优先

写任何代码之前，先问：“最简单能工作的东西是什么？”

写完代码后，用这些检查审视它：

• 能用更少代码完成吗？
• 这些抽象值得它们带来的复杂度吗？
• staff engineer 看了会不会说“为什么不直接……”？
• 我是在为假想的未来需求构建，还是为当前任务构建？