演化原则：软件架构的主题是变化，而非建筑式的永恒

演化原则宣言”演化优于一步到位”，其立论起点是拆穿一个字面类比制造的假象：软件架构在描述结构、模块、关系这个层面确实和建筑架构相似（软件架构描述系统的模块及其关系，建筑架构描述建筑的部件及其组成方式），但这层字面相似掩盖了一个本质差异——建筑一旦建成（甚至一旦开工）就基本定型不再变化（古埃及金字塔4000多年后仍是当初的架构，明长城600多年后结构未变，美国白宫200年来只做局部扩建，整体结构不变），而软件却必须随业务发展持续变化（对比Windows 1.0与Windows 8、Android 1.6与Android 6.0，前后已经是截然不同的系统）。也就是说，对建筑而言”永恒”是主题，对软件而言”变化”才是主题——即便设计Windows和Android的都是顶尖天才，也不可能在早期版本里就把后期版本的架构设计出来。没有把握住这个本质区别，架构设计就容易陷入”试图一步到位、期望架构不管业务怎么变都稳如磐石”的误区，为此要么照搬业界大公司已公开的方案，要么投入巨大资源做各种预测分析——但这类做法通常投入巨大、落地遥遥无期，即使拼死拼活落了地，事后往往还会发现当初的大量预测和分析根本不靠谱。正确的类比对象其实是生物演化：生物先适应当时的环境，通过繁殖把有利基因传下去、淘汰不利基因，环境变化时能快速调整适应，调整不了的就被淘汰，而新生物会继承旧生物的部分基因；软件架构同理，应该先满足当下的业务需要，在实际运行中不断迭代（保留优秀设计、修复缺陷设计、去掉无用设计），业务发生变化时架构随之扩展、重构甚至重写，代码可能重写，但有价值的经验、教训、逻辑和设计会像基因一样在新架构里延续下去。即使是资源充裕的大公司团队，设计新系统时同样要遵循这个原则，而不是仗着人多资源多就想一步做到位——业务的发展和变化速度，从来不是任何团队能够完美预测的。

结构图：

flowchart TB
  A["软件架构 vs 建筑架构"]
  A --> B["建筑：永恒是主题<br/>金字塔4000年结构不变<br/>白宫200年只做局部扩建"]
  A --> C["软件：变化才是主题<br/>Windows 1.0→8、Android 1.6→6.0<br/>已是截然不同的系统"]
  C --> D["常见误区：试图一步到位<br/>照搬大公司方案或投入巨大资源做预测分析<br/>→投入大、落地慢、预测常不靠谱"]
  C --> E["正确类比：生物演化"]
  E --> E1["先适应当下环境"]
  E --> E2["繁殖迭代：留有利基因/淘汰不利基因"]
  E --> E3["环境变化时快速调整<br/>调整不了则淘汰，新个体继承旧基因"]
  E1 --> F["软件架构对应做法：<br/>先满足当下业务→运行中持续迭代→<br/>业务变化时扩展/重构/重写，经验与设计如基因般延续"]
  E2 --> F
  E3 --> F