敏捷之父Martin Fowler作序推荐《演进式架构》

290 阅读3分钟

本文摘自《演进式架构》推荐序

长久以来,软件行业都奉行这样一个理念:在开始编写第一行代码前就应该完成架构开发。受到建筑行业的影响,人们认为成功的软件架构在开发过程中不需要修改,而且重新架构往往会导致高成本的报废和返工。

随着敏捷软件开发方法的兴起,这样的架构愿景受到了很大的挑战。预先规划的架构要求在编码前就确定需求,因而催生了分阶段(即瀑布式)的开发方法——在完成需求分析后才开始设计架构,然后再进入构建(编码)阶段。然而,敏捷软件开发方法并不认同“需求是确定的”这样的观点。它发现现代商业中需求不断变化是必然的,并进一步提供了项目规划技术来拥抱受控的变化。

在这个新的敏捷世界里,很多人质疑架构的作用。当然,预先规划的架构无法适应动态的现代业务,但是,还是会有另外一种架构,它以敏捷的方式拥抱变化。如此看来,架构是不断努力的结果,是一个与开发工作紧密结合的过程,这样它才能同时响应不断变化的需求和开发人员的反馈。我们称之为“演进式架构”,正是要强调当无法预测变化时,该架构仍然可以朝着正确的方向发展。

在 ThoughtWorks,我们无时无刻不秉持演进式架构的理念。Rebecca 在 21 世纪初领导了多个重要项目,作为 CTO,她提升了 ThoughtWorks 的技术领导力。Neal 一直密切关注着我们的工作,将我们学到的经验汇总并传播开来。Pat 在开展项目工作的同时也加强了我们的技术领导力。我们始终认为架构是极其重要的,不容忽视。我们虽然也犯过错误,但我们从错误中学习,更好地理解了如何构建出能正确应对各种变化的系统。

构建演进式架构的核心是采取小步变更,然后通过反馈环让团队的每个成员不断地从系统的发展过程中学习。持续交付的兴起使得演进式架构变得切实可行。三位作者通过适应度函数监控架构的状态。他们探索了架构演进的不同方式,并且重视那些通常被别人所忽视的长存数据。在讨论中也理所当然地会经常提及康威定律。

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

Martin Fowler