在软件开发圈子里，一直存在两种截然不同的“世界观”：
一种是演化论（Evolution）：就像搞初创公司，先跑起来再说。小步快跑，不断迭代，复杂度是随着需求“长”出来的。 另一种是工程论（Engineering）：就像造摩天大楼。开工前必须有一套极其详尽的蓝图，把承重、走线、防震全部想透。
现在的流行趋势显然倾向于前者。大家崇尚敏捷，鄙视“过度设计”。但代价呢？
最近读到一篇深度好文《Systems Thinking》，结合我这些年被各种烂代码毒打的经历，我发现我们可能在“敏捷”的幌子下，掉进了一个巨大的坑里。
一、 “屎山”是怎么堆起来的？
很多大厂内部都有成千上万个系统，覆盖了无数业务线。这些系统往往是在几十年间，由不同的技术栈、不同的外包团队、不同的临时方案“演化”而来的。
如果把这些系统看作一个整体，它不是一座大厦，而是一间摇摇欲坠的**“叠叠乐”木屋**。
数据不一致、安全漏洞百出、运维成本高昂……这些问题的根源不在于程序员代码写得烂，而在于**“人工复杂度”的堆积**。
作者提出了一个扎心的观点：如果我们能用“系统思维”从全局设计，目前的系统复杂度起码能降低 10 倍，甚至更多。那些让我们头疼不已的 Bug，大半都是因为我们为了逃避前期的协同成本，而制造出来的“自残式”问题。
二、 逃避“依赖”：短期爽快，长期火葬场
“演化”和“工程”的核心区别，在于对**依赖（Dependencies）**的处理方式。
- 理想状态：成千上万个微服务，像乐高积木一样完全解耦，互不干扰。只要写好自己的那一块，任务就完成了。这是管理层和程序员共同的梦想。
- 残酷现实：现实中几乎没有东西是真正独立的。
当你选择“演化”路线时，你本质上是在无视依赖。你觉得“以后再重
