我的代码能运行。测试通过了。演示也很顺利。
但这个项目感觉就是不对劲。
不是坏了。
也不是有bug。
就是感觉很沉重。仿佛每次新改动都在拖着一笔日益增长的技术债前行。最初我忽略了这种感觉。大家都是这样做的。能编译就能上线，能上线就没问题。对吧？
不对。这种想法悄无声息地出错。
我们对自己说的谎言
我们告诉自己代码能跑就是成功。
但"能跑"是个很低的标准。低得可疑。
代码能跑的同时依然可能：
- 难以理解
- 每次修改都困难重重
- 添加一个小功能都会带来惩罚
这正是发生的情况。每个新功能都比上一个耗时更长。每个修复都引发两个新问题。重构让人提心吊胆而非心满意足。系统不是坏了，而是变得脆弱。
顿悟时刻
这种认识并非源于一次重大失败。
而是来自一个微小的改动。
一个本应一小时完成的事情。
结果，我花了整个晚上不断问自己一个问题：
"如果我改了这个……会引发什么连锁反应？"
就在那时我顿悟了。如果你害怕碰自己写的代码，问题不在代码，而在系统。
功能不是元凶
这是个令人不安的真相。
我并不是在真正构建功能。
我其实是在堆积自己都没完全搞懂的决策。
我优先考虑的是：
- 速度
- 上线
- 进度
- "我以后会清理的"
每个选择在当时看来都合理。但系统会记住。它记得每一个捷径、每一个假设、每一个悄悄变成永久方案的临时补丁。
真正的bug
这个bug不是技术性的，而是思维上的。
我把架构当作产品完成之后才做的事情。
视其为一种奢侈品。当作过早优化。结果发现，架构的关键不在于追求完美。
而在于：
- 让下一次变更成本更低
- 让故障变得可预测
- 让理解成为可能
而我却没有做到这些。
我现在的领悟
好的系统不会让你觉得巧妙，而是让你觉得从容。
你不会问：
- "这会把一切都搞垮吗？"
你会问：
- "这应该放在哪里？"
当你觉得这个问题难以回答时，麻烦就已经来了。
我仍在努力改掉不良的直觉。
我仍在修复那些仓促上线的代码。
但我不再以"它能跑"来衡量成功。
我的衡量标准变成了：这个系统是在与我对抗，还是在与我协作？
那么你呢？
"先上线再说"到底在哪个时点会变成自我设障？
随时随地看视频
