May 2025
Beginner to intermediate
218 pages
2h 30m
Chinese
Content preview from 软件架构指标
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
Start your free trial
第 4 章 使用模块化成熟度指数改进架构 利用模块化成熟度指数改进架构
本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：translation-feedback@oreilly.com
在过去的 20 年中，大量的时间和金钱 ，这些软件系统都是用 Java、C#、PHP 等现代编程语言实现的。开发项目的重点往往是快速实现功能，而不是软件架构的质量。随着时间的推移，这种做法导致了越来越多的技术债务--不必要的复杂性，在维护方面花费了额外的资金。如今，这些系统不得不被称为遗留系统，因为它们的维护和扩展费用高昂、繁琐且不稳定。
本章将讨论如何利用模块化成熟度指数（MMI）来衡量软件系统中的技术债务数量。一个代码库或一个 IT 环境中不同应用程序的模块化成熟度指数为管理层和团队提供了一个指南，用于决定哪些软件系统需要重构，哪些需要替换，哪些不需要担心。这样做的目的是找出哪些技术债务需要解决，从而使架构具有可持续性，降低维护成本。
技术债务
1992 年，沃德-坎宁安（Ward Cunningham）创造了技术债务一词 ："当有意识或无意识地做出错误或次优的技术决策时，就会产生技术债务。这些错误的或次优的决策会导致后期工作的增加，从而使维护和扩展的成本更高"。1"在做出错误决定时，你就开始积累技术债务，如果不想最终过度负债，就需要连本带利地偿还。
在本节中，我将列出两类技术债务，重点是通过架构审查可以发现的技术债务：
- 执行债务
- 源代码中包含所谓的 代码气味，如冗长的方法和空的 catch 块。现在，可以使用各种工具，以基本自动化的方式在源代码中找到实现债务。每个开发团队都应在日常工作中逐步解决这些问题，而无需额外的预算。
- 设计和建筑债务
- 类、包、 子系统、层和模块的设计以及它们之间的依赖关系既不一致又复杂，与计划架构不符。这种欠账无法通过简单的计算和测量来确定，需要进行广泛的架构审查，这将在"确定 MMI 的架构审查 "中介绍。
其他也可被视为软件项目债务的问题领域，如文档缺失、测试覆盖率低、可用性差或硬件不足等，由于不属于技术债务的范畴，在此就不一一列举了。
技术债务的起源
让我们来看看技术债务的起源 和影响。如果在软件开发项目开始时设计了一个高质量的架构，那么我们就可以假设软件系统在开始时很容易维护。如图 4-1 所示，在这个初始阶段，软件系统处于低技术债务走廊，维护工作量相同。
如果系统在维护和整合变更过程中不断扩大，就不可避免地会产生技术债务（如图 4-1 中向上的箭头所示）。软件开发是一个不断学习的过程，首次提出的解决方案很少是最终方案。必须定期对架构进行修订（架构改进，图中箭头向下）。这就形成了一个不断进行维护/更改和架构改进的序列。
图 4-1. 技术债务的起源和影响
如果一个团队能够持续不断地进行扩展和架构改进，那么系统就能保持低廉稳定的维护成本。遗憾的是，对许多预算管理人员来说，架构改进的这一方面在近几年才真正成为现实--对于大多数在 2000 年代初启动的系统来说，为时已晚。
如果不允许开发团队持续减少技术债务，那么随着时间的推移，架构侵蚀将不可避免地发生，如图 4-1 中离开低而稳定的维护成本走廊的上升箭头所示。这一过程被称为架构侵蚀。一旦技术债务堆积如山，维护和更改软件的成本就会越来越高，随之而来的错误也会越来越难以理解，以至于每次更改都会让人痛苦不堪。 ...