十类技术债务来源

技术债务代价高昂：根据已有数据，开发人员由于技术债务而浪费了 23-42% 的时间。

技术债务的积累主要是因为其对业务的影响很难衡量，因此管理层没有太多的动力去关注它并积极尝试减少它。技术债务像雪球一样不断增长：

• 通常，缺乏时间/预算来正确完成项目，因此新项目会产生技术债务
• 偿还现有的技术债务很少成为业务优先事项的一部分 ->由于项目间的依赖关系，开发人员被迫在现有项目中产生更多的技术债务

下面是谷歌的 一项研究 中给出的十类技术债务的定义

技术债务来源	说明
代码需要迁移 或正在进行迁移	迁移可能的原因是因为 1. 扩容的需要 2. 因为强制要求，例如合规或者安全 3. 减少依赖和耦合 4. 技术升级，避免使用已弃用的技术
文档（项目和API）问题	文档问题包括有关项目运行方式的信息或 API 说明等： 1. 有但难以检索 2. 完全没有 3. 不完整或过时
测试质量或覆盖率差	如缺失测试或测试数据不佳，导致系统脆弱、无法稳定测试或频繁回滚。
代码质量	产品架构或项目中的代码设计不良，可能是仓促完成或仅是原型/演示代码。
无用代码（废弃代码）	代码/功能/项目已被替代或升级，但旧代码一直未被移除。
代码退化	代码整体架构和质量随着时间逐步退化，这样的代码处于维护模式下，需要重构或更新。 退化的原因包括 1. 自然退化，代码如果长时间不进行整理和重构，会自然而然的退化 2. 随着时间推移，开发的标准和最佳时间已经变化，但已有代码仍遵循过时的标准
团队缺乏必要的专业知识	这可能是因为员工的缺口和流动，或接手了没有任何交接（无人维护）的代码/项目。
依赖代码或者服务	1. 依赖方不稳定 2. 依赖的新版本发布得非常频繁，或者它们的API和功能经常发生变化 3. 由于依赖问题导致的回滚。
迁移执行不佳或被放弃	原有的迁移计划并没有良好完成，或者迁移到一半终止了，这可能导致需要维护两个版本的代码。
发布流程问题	发布和监控需要进行更新、迁移或维护。