开发人员、架构师和应用程序团队不断追逐技术债务。不管是好是坏，这是一个令人烦恼的问题，经常被踢到路上，直到为时已晚，应用程序开发放缓，新功能延期，测试周期增加，成本上升。在最公开的情况下，应用程序会完全崩溃——就像我们最近在西南航空公司、Twitter、FAA 和其他从未公开过的网站上看到的那样——但你知道你是谁。技术债务从源代码的味道中呈现出多种形式从安全风险到更严重的架构技术债务问题。存在用于扫描源代码质量和安全性的优秀工具，但由于缺乏可观察性、工具和最佳实践，跟踪、基线化和检测架构漂移一直很困难。
架构技术债务到底是什么，我为什么要关心？如果您是负责维护和扩展旧的 Java 或 .NET 单体的架构师或开发人员，您可能已经非常熟悉这个问题。单体应用程序实际上是由其架构（单体）模式定义的，它带有密集的依赖关系、长依赖链，本质上是一个大泥球，对于任何试图理解和跟踪的架构师来说都是不透明的。这就是架构技术债务的本质：类纠缠、深度依赖、死代码、长依赖链、密集拓扑以及缺乏通用代码库，它们困扰着单体、旧应用程序，甚至最近的微服务已经开始类似于巨石本身。
架构可观察性
到目前为止，软件架构师缺乏从他们的角度理解、跟踪和管理技术债务的可观察性和工具。架构债务不是源代码质量或圈复杂度，尽管这些是需要跟踪和管理的关键技术债务元素。问题的切入要深得多，因为这些结构性问题直接影响产品质量、功能交付提前期和测试时间。学术研究强调了分析依赖关系如何为返工、重构和应用程序现代化的复杂性提供主要预测指标。
架构可观察性照亮了应用程序黑匣子和泥球应用程序，使不透明变得透明，因此架构师可以左移进入正在进行的软件开发生命周期。这使他们能够在结构异常爆发为更大的问题之前，以迭代、连续的方式管理、监控和修复结构异常。可观察的架构从工具开始，首先建立基线、设置阈值并检查架构漂移以主动检测关键异常。
需要追踪的五种关键建筑债务形式
克服架构债务是一项挑战，但任何时候开始都不晚。在过去十年中，许多单体应用已经被提升并转移到云端，这应该是您的首要目标。有五个关键因素需要分析、跟踪和制定修复计划。
- 死代码：最难找到的死代码是驻留在应用程序和公共库中的可访问遗留代码，这些代码已过时或不再被任何当前用户流访问。它通常被认为是“僵尸代码”，因为它潜伏在阴影中，没有开发人员真正愿意接触它。找到它需要结合动态和静态分析来确定代码是否存在但从未在生产中访问过。死代码不同于“无法访问的代码”，因为代码实际上在技术上是可以访问的，但实际上不再使用。死代码会随着时间的推移而发展和传播，使重构和现代化工作变得膨胀和复杂化。
- 服务蠕变：通过手动或自动方式设置基线服务拓扑。逐条列出应用程序中的核心业务服务和公共服务，最好是在整个团队可以跟踪的共享位置。定期审核应用程序结构以查看是否添加或删除了新服务，以及是否出于适当的业务或技术原因。
- 公共类：准备重构或重新架构项目的关键方面之一是确定公共类，这些公共类应包含充当共享公共库的核心平台服务。这一关键的现代化最佳实践将减少重复代码和依赖性，将通用服务集中在一个地方。定期观察应用程序以检查应添加到公共库中的新公共类，以防止进一步积累技术债务。
- 服务排他性：一旦您从整体中提取了一个或多个微服务，为这些服务的排他性设定基线并寻找架构漂移将及早标记未来的技术债务。测量和基线服务排他性以确定服务的独立类和资源的百分比，以在引入扩展架构技术债务的新依赖项时发出警报。
- 高负债类别：某些类别比其他类别承担更多的技术债务。根据依赖项、依赖项和大小分析和设置“高债务”类分数，以确定重构的最佳候选者，这将对减少技术债务产生最大影响。
使用自动化工具的主动架构监督将使架构师能够通过设置观察、分析和设置配置基线测量和阈值的时间表来应对这些类型的变化。
架构漂移管理
持续的现代化要求架构师不仅在应用程序的初始设计或需要重新架构或重构时，而且在其应用程序的整个生命周期中都扮演更积极的角色。架构漂移管理为架构师提供了他们所需的可观察性和工具，以保持其架构的领先地位，随着时间的推移实现现代化，并避免下一次技术债务灾难。
