软件系统富于架构远比建筑架构更更变化？|

菏泽炫佑科技

软件系统富于架构远比建筑架构更更变化？|

软件架构在敏捷社区中是有争议的。 根据许多人的经验，建筑只会导致毫无价值的会议和无关的文件软件系统富于架构远比建筑架构更更变化？|，“地图不是领土”这句话恰如其分地概括了这种观点。 然而，架构不佳的应用程序很快就会变得像一辆被遗弃在路边的车辆，无法修复。 那么，在无意义的两极之间是否存在有用的中间立场呢？

部分问题在于架构设计是对软件系统架构工作结果的不恰当的比喻。 与建筑师的作品相比，这个词让人想起承诺乌托邦未来的设计形象。 然而，软件系统的架构比建筑架构更加多样化。 建筑物是静态的软件开发，建筑设计师的工作只做一次。 软件就其本质而言是不断变化和动态的； 当它停止变化时，它就开始死亡。

为了更好地理解软件架构，我们需要追溯架构师这个词的由来。 它来自古希腊词ἀρχι-（arkhi-，“酋长”）+ τέκτων（téktōn，“”）。 建筑是由建造事物的人创造的。 在建筑师的作品中，这种意义已经消失了。 他们中的许多人从未浇筑过地基、搭建过建筑物的框架，也从未安装过水管或暖气管。 设计和施工是分开的。 在软件中情况并非如此，您的构建方式会影响您构建的内容，反之亦然。

软件架构是关于决策，而不是结构

建筑类比导致一些软件架构师过多地关注结构和行为，而不是产生这些结构和行为的决策。 这并不是说结构和行为不重要，而是说它们是思维过程的结果。 如果系统要随着时间的推移继续发展，就必须保留这种思维过程。 了解某人为什么做某事与了解他们做了什么同样重要。 如果代码组织良好并带有注释，那么他们所做的事情应该很容易从代码中看出，但他们这样做的原因却常常被忽视。

原因是软件的架构决策很少是明确的。 几乎每个架构决策都是相互竞争的替代方案之间的妥协。 而且，还有其他选择，如果不尝试并看看它们是如何工作的，就很难看到它们的优点。 了解什么已经尝试过、什么已经被放弃往往比了解什么有效更有价值。 有句老话说，好的判断来自经验，而大多数经验来自错误的判断。

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

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

事实上，考虑到工作的性质，使用软件架构师这样的头衔会发出错误的信息。 现实情况是，许多软件开发人员都在做架构工作，只是他们没有意识到这一点。 每当他们做出有关如何满足质量属性的决策时，他们都会影响系统的架构。 充分了解其背后的决策如何影响系统实现质量目标的能力是改进系统架构的**步。

那么，人们需要哪些技能来提高建筑工作的质量呢？ 有以下几个方面：

建筑意味着不断探索

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

关于探索对于架构发现的重要性，请考虑以下示例：假设您是软件系统开发团队的一员。 根据*初的设计，该系统将处理存储在 SQL 数据库中的结构化表格数据。 现在，该系统需要得到增强，以便能够处理非结构化数据，包括图像和视频，预计这些数据将比系统目前可以处理的数据大得多。 您正在考虑将NoSQL数据库引入您的技术堆栈中以处理新的数据类型，但由于您的团队对此技术没有太多经验，因此需要进行试验以选择合适的数据库产品、配置它并满足新的数据量要求。 必不可少。

当团队解决这些技术问题时，他们会提出自己的假设，这些假设会随着时间的推移而变化，关于哪些方法*能满足所需的 QAR。 他们构建部分解决方案来测试这些假设并根据结果做出决策。 这些关于如何满足 QAR 的决策的总和就是系统的架构。 团队可以通过不同的方式传达这些决策，包括使用文档和图表。 然而，文档和图表不是架构，重要的是决策以及做出这些决策的原因。

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

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

概括

作为一门学科，软件架构需要彻底的改变。 人们对它的看法受到许多关于它需要解决什么问题以及应该如何解决这些问题的旧观念的影响。 将软件架构视为一项持续的活动，努力对系统如何满足质量属性做出假设，然后凭经验证明系统可以满足这些属性，这是软件架构连续性方法的基础。 还需要改变的是将软件架构从与开发无关的委员会中解放出来，交给能够实际实现它并将其变成可执行程序的人（开发人员）手中。 只有这样，我们才能从当今的应用程序中获得所需的弹性和可持续性。

关于作者：

他是一位经验丰富的软件架构师，在创新和应用程序开发方面拥有丰富的背景，对金融服务行业有广泛的了解，拥有丰富的咨询经验和全面的技术基础。 在过去担任一家大型金融服务公司的首席企业架构师期间，他领导了大型架构团队，管理大型并发应用程序开发项目，指导创新计划，并制定战略和业务计划。 他与人合着了《in》（2021 年）和《in》（2015 年）。 他还发表了许多有关该主题的文章，并在多个软件架构会议上发表了演讲。

Kurt 在以反馈驱动的短周期交付工作软件方面拥有 30 多年的经验。 他帮助各种组织采用敏捷软件交付实践，包括大型银行、保险、制造和零售组织以及大型政府机构。 他曾在 、HP、IBM 和 等大型软件交付组织工作或任职，并担任技术行业分析师。 他的主要重点是帮助企业建立强大、自组织、高绩效的团队，提供客户喜爱的解决方案。 他撰写了四本有关软件开发主题的书籍，其中包括《The Nexus for Scrum》。 他在科罗拉多州博尔德工作，担任企业解决方案副总裁。

原文链接：

: 可能不是你想象的那样

炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等