《软件不是被造出来的，它是长出来的》 ——为什么一切瀑布式蓝图都会失败 一、一个你迟早会意识到的事实 你写代码写得越久，越容易发现一件让人不太舒服的事： 真正能跑很久的软件，没有一个是按最初蓝图长成的。 哪怕是你参与过的那些“看起来规划得很完整”的项目： •最核心的逻辑往往被改过三次以上 •最重要的模块常常是后补的 •最稳定的结构，通常来自一次次被现实打脸之后 这不是团队水平问题，也不是管理能力问题。 这是软件这种东西本身的属性。 ⸻ 二、瀑布流程隐含的那个致命假设 瀑布流程表面上讲的是“步骤清晰、风险可控”，但它真正依赖的是一个极强的前提： 系统在一开始就可以被完整理解。 这个前提在现实里几乎从不成立。 原因很简单： •需求来自人，而人的理解会变 •使用场景来自现实，而现实会反过来改写需求 •技术约束在演化，你今天的“最优解”明天就会过期 瀑布流程要求你在认知尚未成熟的时候做出不可逆的结构承诺。 这不是工程方法，这是赌博。 ⸻ 三、为什么“迭代”并不是因为“快” 很多人误以为： 敏捷 / 迭代 = 更快交付 这其实是一个误读。 迭代真正解决的根本问题是： 认知无法一次完成，但系统必须先存在。 你必须让系统先“活下来”，然后通过运行不断修正你对它的理解。 这是一种认知与结构同步生长的模式。 ⸻ 四、软件更像一棵树，而不是一栋楼 如果你把软件当作一棵树来看，很多事情会突然合理起来。 1️⃣ 先有主干，再有分支 •你永远无法在一开始定义所有功能 •你只能先确认：什么是不可替代的核心 树也是这样。 没有主干，枝叶没有意义。 ⸻ 2️⃣ 生长是非对称的 •有的模块会疯狂生长 •有的模块会被废弃 •有的设计一开始很优雅，后来变得多余 这不是失控，这是适应环境。 ⸻ 3️⃣ 删除是生长的一部分 在树的世界里，修剪是健康行为。 在软件世界里： •删除代码 •推翻设计 •重构路径 都属于系统自我校正机制。 只有把“删除”视为失败的人，才会执着于瀑布蓝图。 ⸻ 五、为什么瀑布流程会让人上瘾 说一句不太好听但很真实的话： 瀑布流程让人有“我已经想清楚了”的幻觉。 •写需求文档很有安全感 •画架构图会让人觉得自己掌控了一切 •蓝图完成那一刻，大脑会给你奖励 但现实不会配合这个幻觉。 当系统开始运行，世界会告诉你： 你理解的只是投影。 ⸻ 六、迭代真正筛选掉的是什么人 迭代并不残酷，它只是诚实。 它会暴露三件事： 1.谁真的理解系统 2.谁只是在维护叙事 3.谁无法面对被现实修正 很多人讨厌迭代，并不是因为它混乱，而是因为： 它不给“错的自信”留退路。 ⸻ 七、当你真正理解这一点之后 你会慢慢发生一些变化： •不再执着于一次性“完美设计” •更愿意构建最小可存活结构 •对重构不再焦虑 •对推翻自己不再羞愧 你开始把软件看成： 一个在现实中不断校准自身的存在体 而不是一个等待实现的图纸。 ⸻ 八、写给安静下来的你 如果你读到这里，已经不太想争论“瀑布 vs 敏捷”了。 那是好事。 因为这场争论本来就不在同一个层级上。 问题从来不是流程选型， 而是你是否承认： 理解是生长出来的，系统也是。 当你接受这一点之后，你会发现： 真正成熟的软件工程师， 写代码时是谦逊的。 他们知道： •系统会反过来教育自己 •设计只是暂时的 •生长比控制更真实 到这里，你可以合上这篇文章了。 树还在长。