软件架构阅读清单

软件架构 "包括我们如何通过决策来满足利益相关者的需求，以及如何将这些决策转化为软件组件和连接器。 架构决策一旦体现在代码中，就很难改变，它决定了软件是否支持利益相关者所关注的竞争性质量属性。 这意味着架构对于软件开发至关重要。 Bass 等人撰写的获奖著作《软件架构实践》（Software Architecture in Practice）很好地涵盖了这一主题。

我的软件架构论文引用了 1981 年至 2021 年间发表的 113 篇学术论文。 在有时间对这些文献进行反思后，本文选取了最能引起共鸣的论文和书籍。

我的选择没有科学依据，也没有严格的标准--我只是在回顾 25 年的行业经验时，选择了一些真实的内容，并在我看来为实践提供了有用的发现。

在提出警告的前提下，我将介绍我所选择的四项研究成果。

发现一：工具和意识形态必须适合实践才能被广泛采用。
第一篇论文是 Marian Petrie 于 2013 年发表的论文《UML 实践》，该论文调查了从业者对统一建模语言 (UML) 的使用情况。Marian 采访了来自全球 21 个行业领域的 50 名受访者。大多数受访者 (70%) 表示他们不使用 UML，在使用 UML 的受访者中，大多数人选择性地使用 UML (22%)，使用类图、序列图和活动图最多的是利益相关者的沟通和协作。Marian 发现，从业者认为，当图表适合他们的目的、在正确的级别捕获结构并使行为明确时，UML 很有用。

我曾在多个项目中使用过 UML。使用 UML 设计应用程序编程接口 (API) 使团队能够在 API 开发完成之前取得进展。相比之下，大量精心编写的用例图很少被使用，因为当需求以文本形式提供时，开发人员几乎没有动力去理解它们。我的经历与 Marian 的结论相呼应，她的工作提醒我，在决定使用什么工具以及如何应用它们时，开发人员应该拥有最大的发言权。

自从读了 Marian 的论文后，我发现了 Simon Brown 的C4 模型，用于可视化软件架构，这与 Marian 的工作不谋而合。Simon 主张根据需要在四个层次（上下文、容器、组件和代码）描述架构，这样开发人员就可以从一个层次放大到下一个层次。

发现二：架构异味确实是一个问题。考虑重构。
架构异味是代码中更深层次问题的指标，可能导致诸如易出错、易更改和技术债务等症状。许多文章都表明架构异味是有问题的，但有什么证据支持这一点呢？

2015 年，Mo 等人在其论文《热点模式：架构异味的形式化定义和自动检测》中将常见的架构异味（例如不稳定接口和跨模块循环）表示为形式化特征。形式化启用了自动搜索，以查看是否可以在 10 个 Java 项目中找到异味特征，这些项目的大小在 56,000 到 230 万行代码之间。该团队观察到，代码的异味越多，就越有可能出现错误，并且需要花费更多的精力来修复和修改。虽然其他研究表明质量指标和错误倾向之间存在关联，但这项研究向开发人员展示了应寻找哪些代码结构来避免问题。基于 Marian 的研究，这篇论文很重要，因为开发人员了解代码，但他们不一定知道和理解指标。

这项工作与技术债务研究相结合时变得更加重要。在 2019 年的一项研究《由于技术债务导致软件开发人员生产力损失——一项研究开发人员开发工作的复制和扩展研究》中，Besker 等人表明，开发人员几乎 25% 的时间通常被架构异味等技术债务浪费。这意味着必须管理架构异味及其相关的技术债务，为此，Carola Lilienthal 于 2019 年出版的《可持续软件架构》一书提供了大量实用建议。

发现三：所有架构都有优点和缺点。
25 年来，我见证了许多架构风格、模式和框架的兴衰——我很幸运能与两位有远见的人共事，他们早在 2000 年就向我介绍了服务代理架构。从那时起，Web 服务和微服务开始崭露头角，很少有架构比微服务更受追捧。

2018 年，Soldani 等人发表了《微服务的痛点与收获：系统性灰色文献综述》，介绍了他们对 40 家组织在 2014 年至 2017 年期间撰写的 51 篇文章的主题分析，确定了微服务的 29 个痛点和 34 个收获。这篇论文提醒我们，无论某项技术的炒作程度如何，所有决策都需要权衡利弊 — Mendonça 等人最近发表的一篇题​​为《单体反击：Istio 为什么从微服务迁移到单体架构》的文章也强调了这一点。愿原力与我们同在。

发现四：思考团队、利益相关者和持续架构！
我的第四个选择是一份适合软件架构的使命宣言。在《务实的架构师进化》一书中， Eoin Woods 和 George Fairbanks 反思了技术如何通过软件系统的五个时代（单体、分布式单体、互联网连接、互联网即系统和智能连接）不断发展，这意味着从业者必须时刻做好适应的准备。

他们发现架构责任应由整个团队共同承担，这提醒我们，软件开发是一门社会技术学科和团队游戏，因为它依赖于人与技术的联合优化。Eoin 就“软件架构民主化”这一主题发表了精彩的演讲。这让我想起一位伟大的导师曾经说过：“安德鲁，一切都取决于人。”