关闭

利用依赖结构矩阵管理架构债务

发表于:2024-7-12 10:10

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:DeepNoMind    来源:DeepNoMind

#
架构
  技术债务(Technical Debt)是软件开发的热门话题,随着时间推移,源代码逐渐增多,技术债务也变得越来越复杂。有很多分析技术债务的工具,基本上都专注于代码质量。架构债务是技术债务的一部分,但由于没有像技术债务那样的自动化工具,因此并不容易确定。
  在确定架构债务时,应研究与源代码耦合的"架构反模式"。以下是需要确定和消除的常见架构反模式:
  ·不稳定接口:这些接口通常是系统的应用程序接口或入口点,有许多依赖组件,接口的微小改动都会让所有依赖组件头疼不已。
  · 违反模块化原则:软件系统应采用模块化架构。这意味着可变更组件应架构在同一模块中,以避免模块间的依赖。如果一个模块的变化对其他模块产生了巨大影响,就应该研究这一不稳定的根本原因。
  · 不健康的继承:当超类依赖于子类或调用者类依赖于超类和子类实例时,就会出现这种情况。
  · 循环依赖:例如,当组件 A 依赖于组件 B,而组件 B 又依赖于组件 C,组件 C 又依赖于组件 A,就产生了循环依赖。这种情况应通过"依赖倒置原则(Dependency Inversion Principle)"加以避免。
  · 软件包循环:多个软件包或插件混乱的相互依赖,而不是形成等级依赖关系。
  · 交叉:依赖于多个其他类的上帝类,另一方面,众多不同的类又依赖于这个特定的类。
  为了避免这些架构反模式,软件架构师应考虑实施 S.O.L.I.D.原则、GoF 设计模式、耦合原则/组件原则。
  下面是示例性现金流 Spring Boot 应用的 UML,可以在 git 仓库[2]中查看源代码。如你所见,该项目由三个基础包构成:api、core、database,采用分层模式。api负责向外部调用者公开restful API,core包含内部所有与业务相关的代码,而database则专注于数据库层。
现金流应用程序的 UML 图
  在研究了现金流应用程序的 UML 图之后,我们来生成系统的依赖结构矩阵(Dependency Structure Matrix)。我通过 Jarchitect[3] 工具生成矩阵,但此外还有很多替代方法:如 Intellij 或 Ndepend[4] 的 DSM[5] 支持。列和行代表 Spring Boot 应用程序 src 文件夹中的 Java 类,它们的结构是对称的。第 8 列是 IncomeService,与第 8 行对应的是相同的类/接口。单元格中的数字表示类之间的静态依赖导入。例如第 12 列(ConverterServiceImpl.java)在第4/5/10行中标了1,表示该类实现了 ConverterService、ExpenseConverterService、Service.
现金流应用的依赖结构矩阵
  为了通过 DSM 找到架构债务,人们应该寻找:
  · 循环调用:A 类调用 B 类,B 类调用 A 类
  · 交叉:数字大的单元格意味着依赖关系多
  · 数字应围绕对角线分配:意味着类具有很强的内凝性
  · 矩阵中的数字越混乱,意味着依赖结构越不安全
  · 评估 S.O.L.I.D 原则,研究持有接口的列数
  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2024软件测试行业从业人员调查问卷》,您的见解,行业的声音!

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号