软件架构可能不是你想象的那个样子

软件架构在敏捷 区中存在争议。在许多人的经验中，架构只会导致毫无价值的会议和无关紧要的文件，“地图不是领土”的说法可以恰当地概括这一观点。然而，架构不佳的应用程序很快就会变得像被遗弃在路边的车辆一样，破损且无法修复。那么，在毫无意义的两极之间是否有一个有用的中间地带呢？

产生这个问题的一部分原因是，对于软件系统架构工作的成果来说，建筑设计是一个不恰当的比喻。对照建筑设计师的工作，这个词会让人联想到预示着乌托邦式美好未来的设计。但是，软件系统的架构远比建筑架构更富于变化。建筑物是静态的，建筑设计师的工作只做一次。软件，就其本质而言，是不断变化的、动态的；当它停止变化时，就开始走向死亡了。

为了更好地理解软件架构，我们有必要追溯下建筑师（architect）这个词的起源。它来自于古希腊词 arkitekton，即?ρχι-（arkhi-，“chief”）+ τ?κτων（téktōn，“builder”）。建筑是由建造东西的人创造的。在建筑设计师的工作中，这种意义已经消失了。他们中的许多人从未浇筑过地基，也没有为建筑物搭过框架，更没有安装过水管或暖气管。设计和建造已经被分开了。但在软件领域却不是这样，构建方式会影响到构建内容，反之亦然。

软件架构关乎决策，而非结构

以建筑物作类比导致一些软件架构师过于关注结构和行为，而不是产生这些结构和行为的决策。这并不是说结构和行为不重要，而是它们是思想过程的结果。如果系统要随着时间的推移持续演进，就必须保留这个思想过程。知道某人为什么做某事与知道他们做了什么同样重要。如果代码组织得很好并且有注释的话，那么它们所做的事情应该很容易从代码中看出来，但是为什么要这样做却常常被忽略。

其原因是，软件的架构决策很少是一目了然的；几乎每一个架构决策都是在相互竞争的备选方案之间做出妥协。而且，有一些备选方案，如果你不尝试一下，看看它们是如何工作的，就很难看出它们的优点。知道试过什么，放弃了什么，往往比知道什么有效更有价值。有句老话说得好，好的判断来自于经验，而大部分的经验来自于坏的判断。

这也是为什么软件架构师必须仍然是开发人员的原因之一；如果不开发和测试一些东西，他们就无法理解或预测系统中的影响因素。软件架构师不应该作为某种酬金，付给那些已经从活跃的开发中退出，但拥有的知识被组织认为仍然有价值的人；它的意义应该不止于此。架构工作需要对系统有足够的了解，以便能够提出有益于质量属性的假设，还需要有编写代码和设计测试以评估假设的专业知识（或与能够评估这些假设的团队成员紧密合作）。

架构是一项技能，而架构师不是一种角色

事实上，就工作性质而言，使用像软件架构师这样的头衔传达了错误的信息。现实情况是，很多软件开发人员都在做架构工作，只是他们没有意识到这一点。只要他们对如何满足质量属性做出决策，就会影响到系统的架构。充分了解背后的决策如何影响系统实现质量目标的能力，是改进系统架构的第一步。

那么，人们需要掌握什么样的技能来提高其架构工作的质量呢？有以下几个方面：

架构意味着持续探索

现代软件应用程序架构设计是一项基础性的探索活动。现如今，构建应用程序的团队每天都会遇到新的挑战：前所未有的技术挑战，以及为客户提供解决新问题和其他各种问题的新方法。这种持续性的探索意味着架构不能根据过去的经验预先确定；团队必须找到满足质量要求的新方法。

关于探索对于架构发现的重要性，请考虑这样一个例子：假设你是一个从事软件系统开发工作的团队的一员。根据最初的设计，该系统是为了处理存储在 SQL 数据库中的结构化表格数据。现在，这个系统需要增强，以便可以处理非结构化数据，包括图像和视频，而且数据量预计会比系统目前处理的多得多。你考虑在技术栈中引入 NoSQL 数据库来处理新的数据类型，但由于你的团队在这项技术上没有多少经验，所以要选择合适的数据库产品，进行配置并满足新的数据量要求，实验必不可少。

在团队解决这些技术问题的过程中，关于哪些方法能最好地满足所期望的 QAR，他们形成了自己的假设，这些假设会随着时间变化。他们构建一部分解决方案来检验这些假设，并根据结果做出决策。这些关于如何满足 QAR 的决策叠加起来就是系统的架构。团队可能会以不同的方式沟通这些决策，包括使用文档和图表。但是，文档和图表不是架构，重要的是决策以及做出决策的原因。

关于这些决策，以下信息很重要：

图 1：QAR、决策和技术债务的关系

小结

作为一门学科，软件架构需要做出彻底的改变。人们对它的看法受制于很多关于它需要解决什么问题以及它应该如何去解决这些问题的旧观念。将软件架构视为一项持续性活动，致力于做出关于系统如何满足质量属性的假设，然后通过实证来证明系统能满足这些属性，这是软件架构持续性方法的根本所在。同样需要改变的是，将软件架构从与开发脱节的委员会中分离出来，交到能够真正实现并使其变成可执行程序的人（开发人员）手中。只有这样，我们才能从如今的应用中获得我们需要的弹性和可持续性。

Pierre Pureur 是一位经验丰富的软件架构师，拥有广泛的创新和应用开发背景，和金融服务行业有广泛的接触，拥有广泛的咨询经验和全面的技术基础知识。他过去曾担任一家大型金融服务公司的首席企业架构师，领导大型架构团队，管理大规模并发应用开发项目，指导创新举措，以及制定战略和商业计划。他与人合著了“Continuous Architecture in Practic”（2021）和“Continuous Architecture”（2015）。他还就这一主题发表了许多文章，并在多个软件架构大会上发表演讲。

Kurt Bittner 有超过 30 年在反馈驱动的短周期内交付可工作软件的经验。他曾帮助各种组织采用敏捷软件交付实践，包括大型银行、保险、制造和零售组织，以及大型政府机构。他曾为甲骨文、惠普、IBM 和微软等大型软件交付机构工作或与之合作，并曾担任 Forrester Research 的科技行业分析师。他的主要工作是帮助企业建立强大的、自组织的高效团队，提供客户喜爱的解决方案。他写了四本软件开发主题相关的著作，其中包括 The Nexus Framework for Scaling Scrum。他在科罗拉多州博尔德市工作，担任 Scrum.org 的企业解决方案副总裁。

原文链接：

Software Architecture: It Might Not Be What You Think It Is