构建演化架构前言

长期以来，软件行业一直遵循这样的理念：架构应该在编写第一行代码之前开发并完成。受建筑行业的启发，人们认为成功的软件架构的标志是不需要在开发过程中进行更改的架构，这通常是对由于重新架构事件而导致的报废和返工的高成本的反应。

这种架构愿景受到了敏捷软件方法兴起的严峻挑战。预先规划的架构方法基于这样的理念：需求也应该在编码开始之前确定，从而导致分阶段（或瀑布式）方法，其中需求之后是架构，架构之后是构建（编程）。然而，敏捷世界挑战了固定需求的概念，观察到需求的定期变化是现代世界的商业必要性，并提供项目规划技术来拥抱受控变化。

在这个新的敏捷世界中，许多人质疑架构的作用。当然，预先规划的架构愿景无法适应现代的动态性。但还有另一种架构方法，它以敏捷的方式拥抱变化。在这种观点中，架构是一项持续的努力，它与编程紧密合作，以便架构可以对不断变化的需求以及编程的反馈做出反应。我们称之为演化架构，以强调虽然变化是不可预测的，但架构仍然可以朝着好的方向发展。

在 Thoughtworks，我们沉浸在这个架构世界观中。Rebecca 在本世纪初领导了我们许多最重要的项目，并在担任 CTO 的过程中培养了我们的技术领导力。Neal 一直是我们工作的细心观察者，他综合并传达了我们学到的经验教训。Pat 将他的项目工作与培养我们的技术主管相结合。我们一直认为架构至关重要，不能任其自生自灭。我们犯过错误，但从中吸取了教训，对如何构建能够优雅地响应其目的的许多变化的代码库有了更好的理解。

演化架构的核心是进行小的更改，并建立反馈循环，使每个人都能从系统的发展方式中学习。持续交付 的兴起是使演化架构成为现实的关键推动因素。作者三人组使用适应度函数来监控架构的状态。他们探索了不同类型的架构演化能力，并强调了围绕长期数据的问题——这通常是一个被忽视的话题。康威定律 贯穿了大部分讨论，正如它应该的那样。

虽然我相信我们还有很多关于以演化方式进行软件架构的知识需要学习，但这本书标志着我们目前理解状态的重要路线图。随着越来越多的人认识到软件系统在我们 21 世纪人类世界中的核心作用，了解如何在保持立足点的同时最好地应对变化将成为任何软件领导者的基本技能。

---