原书第1版序

长久以来，软件行业都奉行这样一个理念：在开始编写第一行代码前就应该完成架构开发。与建筑行业一样，人们认为成功的软件架构在开发过程中是不需要修改的，并且重新设计架构往往会导致成本高昂的浪费和返工。

随着敏捷软件开发方法的兴起，这样的架构理念受到了很大的颠覆。预先规划的架构要求在编码前就确定需求，因而催生了分阶段（即瀑布式）的开发方法——在完成需求分析后才开始设计架构，然后再进入构建（编码）阶段。然而，在敏捷的世界观里，确定的需求是不存在的。如今，需求的变化是一种业务需要，而敏捷开发提供了项目规划的技术来拥抱可控的变化。

在这个新的敏捷世界里，很多人质疑架构所扮演的角色。预先规划的架构已经无法适应动态的现代业务，但有另外一种架构，它能够以敏捷的方式拥抱变化。如此看来，架构设计是贯穿始终的，需要与开发工作紧密结合，这样它才能同时响应需求的变化以及开发人员的反馈。我们称之为“演进式架构”，意在强调即使变化无法预测，该架构仍然可以朝着好的方向发展。

在Thoughtworks，我们无时无刻不秉持演进式架构的理念。作为CTO，Rebecca在2000年年初领导了多个重要项目，提升了我们的技术领导力。而Neal一直密切关注着我们的工作，总结我们的经验并传播开来。Pat在开展项目工作的同时培养了我们的技术负责人。我们始终认为架构是至关重要的，一刻也不能放任自流。虽然犯过错误，但我们从错误中深刻地学习到如何构建出能优雅应对各种变化的系统。

构建演进式架构的核心是采取小步变更，然后通过反馈环让每个团队成员不断地从系统的发展中学习。持续交付的兴起使演进式架构变得切实可行。三位作者通过适应度函数监控架构的状态。他们探索了不同风格的架构演进，同时也关注那些通常被别人所忽视的遗留数据问题。理所当然地，康威定律也是绕不过的话题。

关于构建演进式软件架构，虽然我们还需要了解很多东西，但本书基于当前的理解给出了基本线路图。随着越来越多的人意识到软件系统在21世纪人类社会中的核心地位，每个软件领导者都应该知道如何在发展中以最好的姿态应对变化。

——Martin Fowler

martinfowler.com

2017年9月