2 为什么软件架构很重要？_软件构造为什么重要-优快云博客

本文链接：https://blog.youkuaiyun.com/susemm/article/details/129274383

本文阐述了软件架构在系统质量、变更管理、预测系统性能、利益相关者沟通等方面的重要性。架构决定了系统的质量属性，如性能、可修改性、安全性等，并影响变更的论证和管理。同时，架构有助于预测系统质量，促进团队间的沟通，以及为增量开发和成本估算提供基础。此外，文章还讨论了架构在组织结构、可重用性、设计决策约束等方面的角色。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

文章目录

第2章为什么软件架构很重要？

第2章为什么软件架构很重要？

啊，建造，建造！
这是所有艺术中最崇高的艺术。

—— 亨利・沃兹沃思・朗费罗（Henry Wadsworth Longfellow）

如果架构是答案，那么问题是什么？

本章从技术角度重点关注为什么软件架构很重要。我们将探讨十三个最重要的原因。你可以使用这些原因来推动新架构的创建，或者对现有系统架构进行分析和演进。

架构可以抑制或实现系统的关键质量属性。
架构中的决策使你能够在系统演进时对变更进行推理和管理。
对架构的分析能够及早预测系统的质量。
有文档记录的架构可增强利益相关者之间的沟通。
架构承载着最早的、因而也是最根本的、最难改变的设计决策。
架构定义了对后续实现的一组约束。
架构决定组织的结构，反之亦然。
架构可以为增量开发提供基础。
架构是使架构师和项目经理能够对成本和进度进行推理的关键工件。
架构可以创建为可转移、可重用的模型，从而构成产品线的核心。
基于架构的开发将注意力集中在组件的组装上，而不仅仅是它们的创建上。
通过限制设计选择，架构引导开发人员的创造力，降低设计和系统复杂性。
架构可以成为培训新团队成员的基础。

即使你已经相信我们架构很重要，不需要这一点再被强调十三次，也可以将这十三个要点（构成了本章的大纲）视为在项目中使用架构或证明投入架构的资源合理性的十三种有用方法。

2.1 抑制或实现系统的质量属性

一个系统满足其期望（或要求）质量属性的能力在很大程度上由其架构决定。如果从本书中你什么都没记住，那就记住这一点。

这种关系非常重要，以至于我们在本书的第二部分中用了全部篇幅来详细阐述这一观点。在那之前，先记住这些例子作为一个起点：

如果你的系统需要高性能，那么你需要注意管理元素基于时间的行为、它们对共享资源的使用以及它们之间通信的频率和数量。
如果可修改性很重要，那么你需要注意将职责分配给元素，并限制这些元素的交互（耦合），以便系统的大多数变更只会影响少数这些元素。理想情况下，每个变更只影响单个元素。
如果你的系统必须高度安全，那么你需要管理和保护元素之间的通信，并控制哪些元素被允许访问哪些信息。你可能还需要在架构中引入专门的元素（如授权机制）来建立一个强大强大的 “边界” 以防止入侵。
如果你希望你的系统安全可靠，你需要设计安全防护措施和恢复机制。
如果你认为性能的可扩展性对系统的成功很重要，那么你需要将资源的使用本地化，以便引入更高容量的替代品，并且你必须避免在资源假设或限制上进行硬编码。
如果你的项目需要能够交付系统的增量子集，那么你必须管理组件间的使用。
如果你希望系统中的元素在其他系统中可重用，那么你需要限制元素之间的耦合，以便当你提取一个元素时，它不会因为与当前环境有太多的关联而变得难以使用。

这些和其他质量属性的策略在很大程度上是架构性的。但是，仅靠架构不能保证系统所需的功能或质量。糟糕的下游设计或实现决策总是会破坏一个适当的架构设计。正如我们喜欢说的（大部分是开玩笑）：架构给予的，实现可能会拿走。在生命周期的所有阶段（从架构设计到编码、实现和测试）的决策都会影响系统质量。因此，质量不完全是架构设计的事。但这是质量的起点。

2.2 对变更进行推理和管理

这是前一点的必然结果。

可修改性（对系统进行变更的容易程度）是一种质量属性（因此在前一节的论述中有所涉及），但它是如此重要的一种质量属性，以至于我们在 “十三个要点” 中专门为它留出了一个位置。软件开发社区社区正在认识到这样一个事实：一个典型软件系统的总成本中大约有 80% 是在初始部署之后产生的。大多数人们所从事的系统都都处于这个阶段。许多程序员和软件设计师永远不会从事新的开发工作 —— 他们在现有架构和现有代码体的约束下工作。实际上，所有的软件系统在其生命周期中都会发生变更，以适应新功能、新环境、修复漏洞等等。但现实情况是，这些变更往往充满困难。

每一种架构，无论它是什么，都将可能的变更分为三类：局部变更、非局部变更和架构变更。

局部变更可以通过修改单个元素来实现 —— 例如，向定价逻辑模块添加一个新的业务规则。
非局部变更需要对多个元素进行修改，但保持底层架构方法不变 —— 例如，向定价逻辑模块添加一个新的业务规则，然后向该新业务规则所需的数据库中添加新字段，然后在用户界面中显示应用该规则的结果。
架构变更会影响元素之间相互交互的基本方式，并且可能需要在整个系统中进行变更 —— 例如，将一个系统从单线程改为多线程。

显然，局部变更是最理想的，所以一个 “有效的” 架构是那种最常见的变更是局部的，因而容易实现的架构。非局部变更不是那么理想，但确实有一个优点，即它们通常可以分阶段 —— 也就是逐步 —— 以有序的方式随着时间推出。例如，你可能首先进行变更以添加一个新的定价规则，然后进行变更以实际部署这个新规则。

决定何时变更至关重要、确定哪些变更路径风险最小、评估提议变更的后果以及对请求的变更进行排序和确定优先级，所有这些都需要对系统软件元素的关系、性能和行为有广泛的了解。这些任务都是架构师工作职责的一部分。对架构进行推理和分析架构可以提供对预期变更做出决策所需的见解。如果你不采取这一步骤，并且如果你不注意保持架构的概念完整性，那么你几乎肯定会积累 “架构债务”。我们将在第 23 章中讨论这个问题。

2.3 预测系统质量

这一点是前两点的延续：架构不仅赋予系统质量属性，而且是以可预测的方式做到这一点。

这可能看起来很明显，但情况并非必然如此。否则，设计架构将包括做出一系列几乎是随机的设计决策、构建系统、测试质量属性并寄希望于最好的结果。哎呀 —— 不够快或者极易受到攻击？那就开始胡乱修改吧。

幸运的是，仅基于对系统架构的评估就有可能对系统的质量进行预测。如果我们知道某些类型的架构决策会导致系统中的某些质量属性，那么我们就可以做出这些决策，并合理地期望获得相关的质量属性作为回报。在事后，当我们检查一个架构时，我们可以确定是否已经做出了这些决策，并自信地预测该架构将展现出相关的质量。

这一点和前一点结合起来意味着架构在很大程度上决定了系统的质量属性，而且（更好的是！）我们知道它是如何做到的，并且我们知道如何让它这样做。

即使你没有进行有时为确保架构将提供其规定的好处所必需的定量分析建模，基于质量属性影响评估决策的这一原则至少在早期发现潜在问题方面也是非常宝贵的。

2.4 利益相关者之间的沟通

在第 1 章中提到的一点是，架构是一种抽象，这很有用，因为它代表了整个系统的简化模型，（与整个系统的无限细节不同）你可以将其记在脑海中。你的团队中的其他人也可以。架构代表了一个系统的共同抽象，系统的大多数（如果不是全部）利益相关者可以将其用作建立相互理解、进行协商、形成共识以及相互沟通的基础。架构（或者至少是其一部分）足够抽象，以至于大多数非技术人员在一定程度上可以理解他们所需的内容，特别是在架构师的一些指导下，而且这种抽象可以细化为足够丰富的技术规范，以指导实现、集成、测试和部署。

软件系统的每个利益相关者（客户、用户、项目经理、编码人员、测试人员等等）都关注受系统架构影响的系统的不同特性。例如：

用户关心系统快速、可靠且在需要时可用；
客户（为系统付费的人）关心架构能够按时并按照预算实现；
经理担心（除了成本和进度问题之外）架构将允许团队在很大程度上独立工作，以有纪律和受控制的方式进行交互；
架构师担心实现所有这些目标的策略。

架构提供了一种共同的语言，在这种语言中，可以在即使对于大型、复杂系统也在智力上可管理的层面上表达、协商和解决不同的关注点。没有这样一种语言，就很难充分理解大型系统，以做出影响质量和实用性的早期决策。正如我们将在第 21 章中看到的，架构分析既依赖于这种沟通水平，又对其进行了增强。

关于架构文档的第 22 章将更深入地探讨利益相关者及其关注点。

“按下这个按钮会发生什么？”：架构作为利益相关者沟通的工具

项目评审冗长而沉闷地进行着。这个由政府资助的开发项目进度落后且超出预算，而且由于规模庞大，这些失误引起了美国国会的关注。现在，政府为弥补过去的疏忽，正在举行一场马拉松式的全员评审会议。承包商最近经历了一次收购，这对事情毫无帮助。现在是第二天下午，议程安排是介绍软件架构。年轻的架构师（系统首席架构师的助手）勇敢地解释着这个庞大系统的软件架构将如何使其满足极其苛刻的实时性、分布式和高可靠性要求。他有一个扎实的演示和一个扎实的架构要介绍。它既合理又明智。但是听众（大约 30 名在这个棘手项目的管理和监督中扮演不同角色的政府代表）都很疲惫。他们中的一些人甚至在想，也许他们应该去从事房地产行业，而不是再忍受这样一场马拉松式的 “这次一定要把事情做好” 的评审。

幻灯片以半正式的方框和线条符号展示了系统运行时视图中的主要软件元素。名称都是首字母缩写，没有解释的话没有语义，年轻的架构师进行了解释。线条表示数据流、消息传递和进程同步。正如架构师所解释的，元素是内部冗余的。“在发生故障时，” 他开始说道，用激光笔指着其中一条线，“一个重启机制会沿着这条路径触发，当……”

“按下模式选择按钮会发生什么？” 一位听众打断了他。他是代表这个系统用户群体的政府参会者。

“对不起，你说什么？” 架构师问道。

“模式选择按钮，” 他说。“按下它会发生什么？”

“嗯，那会在设备驱动程序中触发一个事件，在这里，” 架构师开始用激光笔指着说。“然后它读取寄存器并解释事件代码。如果是模式选择，那么，它会向黑板发送信号，黑板又会向订阅了该事件的对象发送信号……”

“不，我的意思是系统会做什么，” 提问者打断了他。“它会重置显示器吗？如果在系统重新配置期间发生这种情况会怎样？”

架构师看起来有点惊讶，关掉了激光笔。这不是一个架构问题，但由于他是架构师，因此对需求很熟悉，他知道答案。“如果命令行处于设置模式，显示器将重置，” 他说。“否则，控制台上会出现一个错误消息，但信号将被忽略。” 他又打开了激光笔。“现在，回到我刚才正在说的重启机制……”

“嗯，我只是在想，” 用户代表说。“因为我从你的图表中看到显示控制台正在向目标位置模块发送信号流量。”

“应该发生什么？” 另一位听众成员问第一个提问者。“你真的希望用户在系统重新配置期间获取模式数据吗？” 在接下来的 45 分钟里，架构师看着听众们占用了他的时间，就系统在各种深奥状态下应该有什么样的正确行为进行辩论 —— 这是一场绝对必要的对话，本应该在制定需求时进行，但由于某种原因没有进行。

这场辩论不是关于架构的，但架构（以及它的图形表示）引发了辩论。很自然地会认为架构是除了架构师和开发人员之外的一些利益相关者之间沟通的基础：例如，经理们使用架构来创建团队并在团队之间分配资源。但是用户呢？毕竟，架构对用户来说是不可见的；为什么他们会把它当作理解系统的工具呢？

事实是他们确实会这样做。在这种情况下，提问者已经听了两天关于功能、操作、用户界面和测试的幻灯片。但正是第一张关于架构的幻灯片（尽管他很疲惫，想回家）让他意识到他不明白一些事情。参加过许多架构审查让我确信，以一种新的方式看待系统会刺激思维并引出新的问题。对于用户来说，架构常常作为这种新的方式，而用户提出的问题将是行为性质的。在几年前一次令人难忘的架构评估活动中，用户代表对系统将要做什么比对它将如何做更感兴趣，这是很自然的。在那之前，他们与供应商的唯一接触是通过其营销人员。架构师是他们能够接触到的关于系统的第一个合法专家，他们毫不犹豫地抓住了这个机会。

当然，仔细而全面的需求规格说明会改善这种情况，但由于各种原因，它们并不总是被创建或可用。在没有需求规格说明的情况下，架构的规格说明常常会引发问题并提高清晰度。认识到这种可能性比抵制它可能更为明智。

有时这样的活动会揭示不合理的需求，然后可以重新审视其效用。这种强调需求和架构之间协同作用的审查类型会让我们故事中的年轻架构师从困境中解脱出来，在整个审查会议中给他一个位置来处理那种信息。而用户代表也不会觉得自己在不恰当的时候提出问题而不自在了。

—PCC

2.5 早期设计决策

软件架构是关于一个系统的最早设计决策的体现，这些早期的决策在系统的后续开发、部署和维护生命周期中具有巨大的影响力。这也是能够对影响系统的这些重要设计决策进行仔细审查的最早阶段。

在任何学科中，任何设计都可以看作是一系列决策的过程。当画家绘画时，在开始作画之前，就会决定画布的材料和记录的媒介 —— 油画颜料、水彩颜料、蜡笔。一旦开始作画，其他决策会立即做出：第一条线在哪里，它的粗细如何，它的形状是什么？所有这些早期设计决策对画作的最终外观有很大的影响，并且每个决策都限制了后续的许多决策。单独来看，每个决策可能看起来都没什么问题，但早期的决策尤其具有不成比例的重要性，仅仅是因为它们对后续的很多决策产生影响并加以限制。

架构设计也是如此。架构设计也可以看作是一组决策。改变这些早期决策会产生连锁反应，涉及到现在必须改变的其他决策。是的，有时架构必须进行重构或重新设计，但这不是一个我们可以轻易进行的任务 —— 因为这个 “连锁反应” 可能会变成一场雪崩。

软件架构所体现的这些早期设计决策是什么呢？考虑以下几点：

系统将在一个处理器上运行还是分布在多个处理器上？
软件会分层吗？如果是，会有多少层？每一层将做什么？
组件之间的通信是同步的还是异步的？它们通过传递控制信息还是数据进行交互，或者两者都有？
在系统中流动的信息会被加密吗？
我们将使用哪个操作系统？
我们将选择哪种通信协议？

想象一下不得不改变这些或无数其他相关决策的噩梦。像这样的决策开始充实架构的一些结构及其相互作用。

2.6 对实现的约束

如果你希望你的实现符合一个架构，那么它就必须符合该架构所规定的设计决策。它必须具有该架构所规定的元素集合，这些元素必须以该架构所规定的方式相互交互，并且每个元素都必须按照该架构的规定履行对其他元素的责任。这些规定中的每一个都是对实现者的约束。

元素构建者必须熟悉他们各自元素的规范，但他们可能不知道架构上的权衡 —— 架构（或架构师）只是以满足权衡的方式对他们进行约束。一个经典的例子是，当架构师为涉及某些更大功能的软件部分分配性能预算时。如果每个软件单元都在其预算范围内，那么整个事务将满足其性能要求。每个组成部分的实现者可能不知道整体预算，而只知道他们自己的预算。

相反，架构师不必是算法设计的所有方面或编程语言的复杂细节的专家 —— 尽管他们当然应该知道得足够多，以免设计出难以构建的东西。然而，架构师是负责建立、分析和执行架构决策和权衡的人。

2.7 对组织架构的影响

架构不仅规定了正在开发的系统的结构，而且这种结构还会铭刻在开发项目的结构中（有时是整个组织的结构中）。在大型项目中划分工作的常规方法是为不同的团队分配系统的不同部分来构建。这种所谓的系统工作分解结构体现在第 1 章所描述的工作分配结构的架构中。由于架构包含了系统最广泛的分解，它通常被用作工作分解结构的基础。工作分解结构进而决定了规划、调度和预算的单位；团队间的沟通渠道；配置控制和文件系统组织；集成与测试计划和程序；甚至是项目的细枝末节，比如项目内部网是如何组织的，公司野餐时谁和谁坐在一起。团队之间根据其元素的接口规范进行沟通。当开展维护活动时，这也会反映软件结构，会组建团队来维护架构中的特定元素 —— 数据库、业务业务规则、用户界面、设备驱动程序等等。

建立工作分解结构的一个副作用是固化软件架构的某些方面。负责其中一个子系统的团队可能会抵制将其职责分配给其他团队。如果这些职责已经在合同关系中正式确定，变更职责可能会变得成本高昂，甚至引发诉讼。

因此，一旦架构达成一致，出于管理和业务原因，对其进行重大修改的成本就会变得非常高。这是（众多理由中的）一个在确定具体选择之前分析大型系统软件架构的理由。

2.8 支持增量式开发

一旦定义了架构，它就可以作为增量式开发的基础。第一个增量可以是一个框架系统，其中至少有一些基础结构（元素如何初始化、通信、共享数据、访问资源、报告错误、记录活动等等）是存在的，但系统的大部分应用功能并不存在。

构建基础结构和构建应用功能可以同时进行。设计并构建一点基础结构来支持一点端到端的功能；重复这个过程直到完成。

许多系统都是作为框架系统构建的，可以使用插件、包或扩展进行扩展。例如 R 语言、Visual Studio Code 和大多数网络浏览器。当添加扩展时，它们在框架已有的功能之上提供额外的功能。这种方法通过确保系统在产品生命周期的早期可执行来辅助开发过程。随着扩展的添加，或者早期版本被这些软件部分的更完整版本所取代，系统的保真度会增加。在某些情况下，这些部分可能是最终功能的低保真版本或原型；在其他情况下，它们可能是仅以适当的速率消耗和产生数据但几乎不做其他事情的 “替代品”。除此之外，这允许在产品生命周期的早期识别潜在的性能（和其他）问题。

这种实践在 21 世纪初通过阿利斯泰尔・科克本（Alistair Cockburn）的思想及其 “行走的骨架” 概念而受到关注。最近，采用 MVP（最小可行产品）作为降低风险策略的人也采用了这种方法。

增量式开发的好处包括降低项目中的潜在风险。如果架构是针对一系列相关系统的，那么基础框架可以在整个系列中重复使用，从而降低每个系统的成本。

2.9 成本和进度估算

成本和进度估算对项目经理来说是一个重要的工具。它们帮助项目经理获取必要的资源，并监控项目的进展。架构师的职责之一是在项目生命周期的早期帮助项目经理创建成本和进度估算。虽然自上而下的估算对于设定目标和分配预算很有用，但基于自下而上理解系统各个部分的成本估算通常比纯粹基于自上而下的系统知识的估算更准确。

正如我们所说，项目的组织和工作分解结构几乎总是基于其架构。负责一个工作项的每个团队或个人将能够比项目经理更准确地估算他们负责的部分，并且在使这些估算成为现实时会有更强的责任感。但是，最好的成本和进度估算通常来自于自上而下的估算（由架构师和项目经理创建）和自下而上的估算（由开发人员创建）之间的共识。这个过程中产生的讨论和协商所创建的估算比单独使用任何一种方法都要准确得多。

如果对系统的需求进行了审查和验证，会很有帮助。你对范围了解得越多，成本和进度估算就会越准确。

第 24 章深入探讨了架构在项目管理中的使用。

2.10 可转移、可重用的模型

在生命周期中越早应用重用，就能从这种实践中获得越大的收益。虽然代码重用有好处，但架构的重用为具有类似需求的系统提供了巨大的影响力机会。当架构决策可以在多个系统中重用时，我们在前面章节中描述的所有早期决策的后果也会转移到那些系统中。

产品线或产品族是一组系统，它们都是使用相同的一组共享资产构建的 —— 软件组件、需求文档、测试用例等等。这些资产中最重要的是为满足整个产品族的需求而设计的架构。产品线架构师选择一个架构（或一组密切相关的架构），它将服务于产品线中所有可预见的成员。架构定义了对于产品线的所有成员来说什么是固定的，什么是可变的。

产品线代表了一种强大的多系统开发方法，在上市时间、成本、生产力和产品质量方面已经显示出数量级的回报。架构的力量是这种范式的核心。与其他资本投资类似，产品线的架构成为开发组织的共享资产。

2.11 架构允许纳入独立开发的元素

早期的软件范式将 “编程（programming）” 作为主要活动，以代码行数来衡量进展，而基于架构的开发通常侧重于 “组合（composing）” 或 “组装元素（assembling elements）”，这些元素很可能是分别甚至独立开发的。这种组合是可能的，因为架构定义了可以纳入系统的元素。架构根据元素与环境的交互方式、接收和放弃控制的方式、消耗和产生的数据、访问数据的方式以及用于通信和资源共享的协议来约束可能的替换（或添加）。我们将在第 15 章中详细阐述这些想法。

商用现成组件、开源软件、公开可用的应用程序和网络服务都是独立开发元素的例子。将许多独立开发的元素集成到你的系统中的复杂性和普遍性催生了一整个软件工具行业，例如 Apache Ant、Apache Maven、MSBuild 和 Jenkins。

对于软件来说，回报可能有以下形式：

缩短上市时间（使用别人现成的解决方案应该比自己构建更容易。）
提高可靠性（广泛使用的软件应该已经消除了其漏洞。）
降低成本（软件供应商可以在其客户群中分摊开发成本。）
增加灵活性（如果你想要购买的元素不是非常特定用途的，它很可能有多个来源，这反过来又增加了你的购买影响力。）

一个 “开放系统” 是定义了一组软件元素标准的系统 —— 它们的行为方式、与其他元素的交互方式、如何共享数据等等。开放系统的目标是使许多不同的供应商能够生产元素，并甚至鼓励他们这样做。这可以避免 “供应商锁定”，即只有一个供应商能够提供一个元素并为此收取高价的情况。开放系统是由定义元素及其交互的架构实现的。