软件架构师速成指南

第 3 章. 生活在第一衍生物中的建筑师

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

在不断变化的世界中，你目前的职位意义不大

得出对建筑的需求

定义 一个系统的架构是在许多经常相互冲突的目标之间进行平衡的过程：灵活的系统可能很复杂；高性能的系统可能很难理解；易于维护的系统可能需要花费更多的精力来初步构建。尽管这正是架构师的工作如此有趣的原因，但这也使其难以确定究竟是什么在推动架构决策。

变化率决定架构

如果非要我说出一个影响架构的主要因素，我会把变化率放在首位，这是对反向问题的推理：什么时候一个系统根本不需要任何架构？ 虽然作为一个架构师，这不是一个自然而然要问的（也不是要回答的）问题，但它可以揭示是什么系统属性使架构变得有价值。 在我看来，唯一不会从架构中受益的系统是一个根本不会变化的系统。如果一个系统的所有东西都是百分之百固定不变的，那么只要让它以某种方式运转起来就足够了。

现在，将逻辑还原到最初的命题，变化的速度自然是架构价值和架构决策的主要驱动力。不难看出，一个不需要经常变化的系统与一个需要长期承受频繁变化的系统相比，其架构会有很大的不同。因此，优秀的架构师要与变化打交道。这就意味着，他们要在系统的 一阶导数中生存：一阶导数是函数值变化快慢的数学表达式。¹

一旦我们了解了变化对架构的影响，就应该考虑影响 IT 系统的各种变化形式。我们首先想到的变化是功能需求的变化，但其实还有很多：需要处理的流量或数据量的变化、将运行环境更改为云、或业务环境的变化，如用不同的语言或不同的人使用系统。

变革 = 不寻常的业务？

尽管人们常说 "唯一不变的就是变化"，但传统的 IT 组织往往与变化有着某种不和谐的关系。一个流行的机房口号"永远不要触碰运行中的系统"（第 12 章）常常揭示了这种心态。当变革无法避免时，IT 部门会将其整齐地打包成一个项目。IT 项目中最值得庆祝的部分是项目结束或启动，而具有讽刺意味的是，这往往是真正的用户第一次真正使用系统。庆祝的原因是一切可以恢复 "照常运行"，即在没有任何改变的情况下稳定运行。

备注

将变革打包到项目中反映了一个组织的信念，即 "不变 "是正常的、理想的状态，而 "变革 "则是断断续续的、不寻常的状态。

因此，许多组织系统都是为了控制和防止变更而设计的：预算编制流程限制了变更支出；质量关限制了投入生产的变更；项目规划和需求文档限制了范围变更。要改造软件交付组织，使其能够接受不断的变化，就必须调整这些流程，以支持而不是阻止变化，同时又不忽视当初设置这些流程的动机（通常是有用的）。这并不是一件容易的事，这也是本书用整整一个部分（第五部分）来讨论转型的原因。

不同的变化率

技术是一个飞速发展的领域：我们不会对带有三个版本号的 IT 产品有太多想法："好吧，如果你还在用 2.4.14，我也帮不了你什么；现在确实是升级到 .15 的时候了"。

幸运的是，IT 行业的发展并非一日千里：最常见的处理器架构，即英特尔 x86 处理器的基础，源自 1978 年。今天移动设备中占主导地位的 ARM 芯片则是基于 1985 年左右的设计。Linux 和 Windows 操作系统都已过了而立之年，就连 Java 也在几年前的第 9 版突破了 20 ...