架构腐化只能延缓无法避免的演进式设计换房子隐喻

[[复杂性的两个来源如何解释微服务规模效应的反转]]谈的是静态的”正确 执行”，治理还有动态的”持续保持”要求——但这个看似只是”守成”的目标， 实际上不可能真正实现：只要系统长期接受新需求输入，质量就必然无法长期 维持，这种现象叫”架构腐化”（Architectural Decay），只能延缓，无法避免。 腐化的过程很像生物衰老：项目立项时团队像小孩子选钟爱的玩具一样认真 挑选技术栈，选型能解决当时能预料到的困难；但随时间推移，高级技术专家 不可能一直陪着项目走到稳定期之后的迭代阶段（反过来，一直守着已稳定 项目的人也很难被培养成技术专家），老人退出新人加入，团队总要在”理解 旧代码”和”完成新功能”之间疲于奔命；代码也会逐渐失控——工期紧、任务重、 不熟悉代码库这些理由会让原则底线被一次次细微突破，破窗效应最终累积成 每个新人一进来就能嗅出的”老朽腐臭味”。治理架构腐化唯一有效的办法是 演进式设计（Evolutionary Design）——这里的”架构师”这个从建筑业借来的 词其实有很大的误导性：万丈高楼是照着预先设计好的完整图纸精确施工建成 的，但没有任何大型软件系统是这样建成的。演进式设计和建筑设计的关键 区别是”造房子”和”换房子”的不同：从学生时代的六人间宿舍，到单间出租屋， 到两室一厅，到学区房，再到梦想中的大别墅——大别墅不是宿舍”添砖加瓦” 升级来的，后一套房子和前一套只有逻辑上的继承关系，没有实质血缘上的 继承。大型软件的建设是不断推倒重来的演进过程，前一版本的价值在于它满足 了那个阶段用户的需要、让团队成功适应了那个阶段的复杂度，这才能向下 一个台阶迈进。