用户反馈与产品迭代
15.6 迭代节奏管理
Tip
软件开发不是修大桥，修好了就不能动了。软件是种树，需要持续修剪、施肥。Agile (敏捷) 的核心就是：不要憋大招，要小步快跑。
1. 为什么要学这个?
你想做一个“完美版 2.0”。 闭关开发了半年，期间没有发布任何更新。 半年后上线，发现市场变了，或者 Bug 太多导致用户无法使用。 用户因为半年没看到更新，以为你跑路了，早就删了 App。
2. 核心概念：CI/CD 与 版本号
2.1 语义化版本 (SemVer)
v1.2.3
- 1 (Major): 重大重构 (不兼容旧版)。
- 2 (Minor): 新功能 (兼容旧版)。
- 3 (Patch): 修 Bug (兼容旧版)。
2.2 发布节奏
- 每日构建 (Nightly): 哪怕只改了一行代码，只要测试通过，就自动部署到测试环境。
- 每周发布 (Weekly): 每周五发一个 Stable 版给用户。
- 小步快跑: 每次只改一点点，出问题了好回滚。
3. 解决方案 (HOW)
3.1 Changelog 驱动开发
在写代码之前，先写 CHANGELOG.md。
“这周我要实现什么？”
如果写不出来，说明目标不清晰。
3.2 Feature Toggles (功能开关)
想上新功能，又怕有 Bug？加个开关：
if (flags.enableNewUI) {
return <NewUI />
} else {
return <OldUI />
}
先把代码部署上去 (默认为关)。验证没问题了，在后台一键开启。 出问题了，一键关闭 (Kill Switch)。不需要重新发版。
3.3 迭代循环图
graph TD
Plan["本周计划"] --> Dev["开发 & 提交"]
Dev --> Test["自动化测试"]
Test --> Deploy["部署 (Feature Flag Off)"]
Deploy --> Verify["线上验证 (开给 1% 用户)"]
Verify --> Release["全量发布 (100%)"]
Release --> Feedback["收集反馈"]
Feedback --> Plan
style Release fill:#c8e6c9,stroke:#2e7d32
4. 避坑指南
| ❌ 不要这样做 | ✅ 应该这样做 | 为什么 |
|---|---|---|
| 憋大招 | 小版本 | Waterfall 模式是敏捷的天敌。发布周期越长，风险越大，回滚越难。 |
| 周五发版 | 周二发版 | 周五傍晚发版 = 周末加班修 Bug。尽量周二/周三发，出了问题周四还能修。 |
| 无 B 计划 | 回滚策略 | 每次发布前都要想好：万一炸了，怎么在 1 分钟内回滚到上个版本？ |
5. 真实案例
Story
骑士资本的 4 亿美元
2012年，骑士资本 (Knight Capital) 更新了一次交易系统代码。 因为测试不充分，且忘了删掉一个旧的 Feature Flag，导致系统错误地疯狂高买低卖。 45 分钟内亏损了 4.4 亿美元。公司直接破产。
Vibe 心法：发布代码的动作就像拆盲盒，风险与惊喜并存。坚持“小步快跑”与“全自动 CI/CD”，能让每一次上线都变得微不足道且可控。通过 Feature Flag 掌控功能的开关，是获得生产环境“豁免权”的关键。
6. 本章小结
- Ship Early, Ship Often：与其追求完美，不如追求速度。
- Feature Flags：让你能控制功能的生杀大权。
- Safety First：永远准备好回滚按钮。