下载掌阅APP，畅读海量书库
立即打开
我们所使用的编程平台也例证了这种持续演进。编程语言的新版本提供了更好的API，以提高应对新问题的灵活性或适用性。新的编程语言也提供了不同的范式和不同的构造集。例如，作为C++的替代品，Java降低了编写网络代码的难度并解决了内存管理存在的问题。回望过去的20年，我们发现很多语言在持续改进它们的API，与此同时新的语言频频涌现以解决新的问题。编程语言的演变如图1-3所示。
图1-3：流行编程语言的演进过程
在软件开发的任何方面——无论是编程平台、语言、运行环境、持久化技术还是云服务——我们可以预见变化会持续发生。尽管我们无法预测何时会发生技术变化或领域格局变化，哪些变化会持续下去，但我们知道变化是无法避免的。因此，我们必须在构建系统的过程中保持对此的清醒认识。
如果生态系统以难以预料的方式持续演进，或者无法预测变化，那么除了固定规划以外我们还有什么选择呢？企业架构师和开发人员必须学会适应变化。长期规划背后有一个传统因素，即财务考虑，软件变更曾经是昂贵的。然而时过境迁，现代工程实践通过自动化过往的手工流程以及诸如DevOps等先进技术降低了变更成本，这个陈述已然失效。
多年以来，许多聪明的开发人员已经意识到系统中的某些部分比其他部分更难以修改。这也是为什么软件架构被定义为“以后难以修改的部分”。这个定义简单明了地区分了软件系统中可以轻松修改的部分和那些真的难以修改的部分。不幸的是，这个定义衍生出一个思考架构的盲点：开发人员预先假设改变是困难的，于是便一语成谶。
几年前，一些富有创新精神的架构师用新的视角审视了“以后难以修改的部分”的问题：如果我们赋予架构可变性会怎样？换种说法，如果把易于修改作为架构的基本原则，那么变更就不再困难。赋予架构可演进性同时也会为其带来一系列新的行为，从而再次扰乱这种动态的平衡。
即使生态系统不变，架构特征也会渐渐腐化，要怎么办呢？架构师设计架构，然后将其暴露在混乱复杂的真实世界中，让各种实现细节覆盖其上。架构师应该如何保护他们所定义的重要部分呢？