变化给架构带来的挑战（草稿）

在软件开发过程中，一次分析、设计、建模、编码，我们面临的复杂问题就能够解决吗？
显然，我们无法忽略随着时间向前而产生的另一种复杂度——变化。我们能显著感受到的伴随着时间而生的外部变化大致可以概括为两种：

1. 随着客户发展而不断变化的需求（用户诉求甚至群体等等变化带来的新需求）
2. 随着认知提升而不断变化的技术（新兴的技术，包括语言、框架、平台等等）

我们无法拒绝这些变化给我们带来的收益：

1. 只要有新的需求，就有新的业务增长点。
2. 新兴的技术带来的是研发和运营成本的降低。

变化的复杂度在于难以预测，团队日复一日的工作就是要应对这种不确定性。但这些变化是团队"接受"并愿意为之奋斗的。原因很简单，团队为之付出的成本可以换来看得见摸得着的收益，这些收益甚至可以用具体的数字进行量化（日活、月活、转化率等等指标都可以换算成价值，而基础设施的云迁移也可以计算出）。

这类变化我称之为『良性』、『显性』的变化。

另一种变化也同时虽则时间在软件和团队内部悄然发生。这类变化值『良性』、『显性』的变化副产物。『良性』、『显性』的变化必然会造成软件和团队的规模变得越来越大。有人加入，有人离开，当初建立其的领域知识不断被稀释，了解来龙去脉和全景的人越来越少。有时候为了满足不断变化的外部需求，急迫地开发上线，根本没有时间去理解并遵守当初做出的设计决策。

这种为了加速软件开发而对最佳实践做出的妥协，被 Ward Cunningham 称为技术债。

这些变化就在团队的眼皮低下发生，但团队往往睁一只眼闭一只眼，原因也很简单，这类变化产生的伤害是隐性的，没有办法估量。开发又不是进行不下去，对吧？

这类变化我称之为『恶性』、『隐性』的变化。

更可怕的是，『恶性』、『隐性』的变化是在一个本身就在动荡的系统上叠加，会让整个系统中的负能量变本加厉的快速膨胀。整个软件系统逐渐滚成大泥球，整个团队陷入焦油坑。这时候才悔之晚矣，系统真的改不动了。

外部的良性变化和内部的恶性变化，都对我们的软件架构都提出了更高的要求。我们的软件架构必须具备一这样一种能力，能够随着时间推移适应变化，持续演进。

这种架构在时间维度上的可演进性在《演进式架构》一书中被明确地提出：

演进式架构支持跨多个维度的引导性增量变更。

接下来的文章中，我们将详细的解释演进式架构的含义。