把待办应用重写三次后，我学到的状态管理

前言

同一个 side project 用三种架构重写的经历，反思状态究竟该放在哪里，以及哪些问题其实是当初选错架构造成的。

常见的翻车姿势

跳过这一步的团队，通常会踩中三种坑：

• 优化了一个没人同意要动的数字。
• 照抄了约束完全不同的项目的方案。
• 一直推迟决策，直到反悔的代价高得吓人。

建议的切入方式

1. 用用户的语言，一句话讲清楚问题。
2. 选择一个每周都能度量的信号，而不是只在上线当天看一眼。
3. 给小实验设定时间盒；两天的 spike 胜过两周的辩论。

小结

如果 Example 教会了我们什么，那就是「无聊的一致性」打赢「聪明的一次性方案」。把学到的东西带回团队，别让它变成口口相传的都市传说。