本文摘自《演进式架构》推荐序
长久以来，软件行业都奉行这样一个理念：在开始编写第一行代码前就应该完成架构开发。受到建筑行业的影响，人们认为成功的软件架构在开发过程中不需要修改，而且重新架构往往会导致高成本的报废和返工。
随着敏捷软件开发方法的兴起，这样的架构愿景受到了很大的挑战。预先规划的架构要求在编码前就确定需求，因而催生了分阶段（即瀑布式）的开发方法——在完成需求分析后才开始设计架构，然后再进入构建（编码）阶段。然而，敏捷软件开发方法并不认同“需求是确定的”这样的观点。它发现现代商业中需求不断变化是必然的，并进一步提供了项目规划技术来拥抱受控的变化。
在这个新的敏捷世界里，很多人质疑架构的作用。当然，预先规划的架构无法适应动态的现代业务，但是，还是会有另外一种架构，它以敏捷的方式拥抱变化。如此看来，架构是不断努力的结果，是一个与开发工作紧密结合的过程，这样它才能同时响应不断变化的需求和开发人员的反馈。我们称之为“演进式架构”，正是要强调当无法预测变化时，该架构仍然可以朝着正确的方向发展。
在 ThoughtWorks，我们无时无刻不秉持演进式架构的理念。Rebecca 在 21 世纪初领导了多个重要项目，作为 CTO，她提升了 ThoughtWorks 的技术领导力。Neal 一直密切关注着我们的工作，将我们学到的经验汇总并传播开来。Pat 在开展项目工作的同时也加强了我们的技术领导力。我们始终认为架构是极其重要的，不容忽视。我们虽然也犯过错误，但我们从错误中学习，更好地理解了如何构建出能正确应对各种变化的系统。
构建演进式架构的核心是采取小步变更，然后通过反馈环让团队的每个成员不断地从系统的发展过程中学习。持续交付的兴起使得演进式架构变得切实可行。三位作者通过适应度函数监控架构的状态。他们探索了架构演进的不同方式，并且重视那些通常被别人所忽视的长存数据。在讨论中也理所当然地会经常提及康威定律。
关于构建演进式软件架构，虽然我们还需要了解很多东西，但本书基于当前的理解给出了基本线路图。随着越来越多的人意识到软件系统在 21 世纪人类社会中的核心地位，每个软件领导者都应该知道如何在发展中以最好的姿态应对变化。
Martin Fowler
