incremental-implementation

name	incremental-implementation
description	Build in thin vertical slices. Use when any change touches more than one file.

增量实现

Overview

永远不要一次性构建整个功能。每个增量是一个薄的垂直切片——从前端到后端贯穿整个栈实现一个小价值单元。实现→测试→验证→提交，一个循环一个切片。这样你永远知道自己改了什么、哪里可能坏了、如何回滚。

When to Use

• 任何改动涉及 2 个以上文件
• 新功能开发（尤其是大型功能）
• 涉及有风险或不确定的技术方案变更
• 多人在同一代码库协作
• NOT for 仅修改 1 个文件且改动量 < 30 行的简单 fix
• NOT for 纯粹的文档或配置变更

Core Process

1. 切分垂直切片 — 每个切片是一个完整的端到端功能点（DB → API → UI），体积小到可以在 15-30 分钟内完成
2. 实现一个切片 — 只写这个切片需要的代码。不要为"以后可能用到"的功能提前铺垫
3. 测试 — 运行该切片相关的所有测试（单元+集成）
4. 验证 — 手动或自动验证行为符合预期（API 调用、UI 检查、日志确认）
5. 提交 — commit 信息清晰描述这个切片做了什么。确保每个 commit 是可部署的（不破坏 main）
6. 重复 — 进入下一个切片

需要使用 Feature Flags 的情况

• 改动涉及破坏性变更
• 新功能需要在特定时间才能上线
• 改动风险较高，需要 A/B 验证
• 改动需要与主分支长期共存但不对用户可见

Rollback 策略

• 每个切片都应可独立回滚
• 数据库变更优先向后兼容（加列不加锁，不改已有数据格式）
• 如果切片依赖尚未上线的 API，使用版本号或适配层隔离

Common Rationalizations

Rationalization	Reality
"先把整个架构搭起来，再填细节"	一次性架构 = 一次性赌注。赌输的概率极高
"就多写了 50 行未来用的代码，没事"	未来用的代码 90% 都不会被用到，但 100% 需要维护
"这个改动太小了不值得提交"	没有"太小不值得提交"的改动，只有"太大无法 review"的改动
"先合到一起，回头再拆"	回头就是永远不
"整个功能做完再测更高效"	整个做完后一个 bug 需要理解整个功能才能修

Red Flags

• 同一个分支上超过 3 天没有提交
• 一个 commit 改了超过 10 个文件
• 代码中出现了"以后会用到"的接口或抽象
• 无法在没有其他切片的情况下独立验证当前切片
• 某个切片的测试覆盖率突然大幅下降

Verification

• 每个切片都是可独立验证的垂直功能
• 每个 commit 只涉及一个逻辑变更
• 无"预留"代码（未被当前切片使用的抽象/接口）
• 所有切片修改的测试在提交前通过
• 如果需要回滚，知道回滚到哪个 commit