14、软件架构技术债务管理与架构师角色探讨

软件架构技术债务管理与架构师角色探讨

1. 技术债务概述

技术债务包含不同类型，其中传染性债务的利息（即延迟解决债务所需的额外努力以及因债务存在导致开发所需的额外努力）高于其他类型的债务。由于无法从系统中消除所有债务，因此需要机制来确定不同类型债务的优先级。在确定优先级时，需要考虑的因素之一就是债务的利息。如果债务项目属于传染性类型，随着时间的推移，重构它的成本会迅速增加。因此，优先解决这类债务可以降低重构成本。

2. 恶性循环模式

在研究中发现了一种恶性循环模式。在一些公司中，架构师识别出需要解决的关键债务项目，经过游说争取到资源后开始重构工作。但在工作过程中，发现之前的工作量估计过于乐观。同时，可能会出现客户的高优先级问题，导致资源被重新分配去解决客户问题。最终，重构工作无法完成。

例如，在一家公司中，由于历史原因，组件之间有三种通信方式，这导致了开发和质量保证过程中的大量开销。架构师成功争取到资源进行重构，用一种新的通信方式取代这三种方式。但重构过程中遇到了上述问题，最终不仅没有完成重构，系统中组件的通信方式反而增加到了四种，使架构债务变得更糟。

这种恶性循环模式下，每个人在局部为系统的长期可行性做出了正确的决策，但整体结果却比不进行改进技术债务的努力还要糟糕。而且不成功的重构努力不仅会使系统比最初预期的更糟糕，还会降低组织其他成员支持重构工作的意愿。

3. 架构技术债务的积累

架构技术债务的积累是不可避免的。一方面，即使最初的架构与系统需求完美匹配，但随着需求的演变，架构会立即与需求不再完美匹配，从而积累债务。另一方面，正常的功能开发也是债务积累的来源。功能开发通常经历四个阶段：