一分钟读论文：《技术债的普遍性、原因和影响：业界系统调查》

据研究，在软件开发组织中平均有25%的成本浪费于解决技术债遗留的问题。塞尔维亚诺维萨德大学、巴西里约热内卢联邦大学、巴伊亚联邦大学和巴西塞阿拉联邦研究所、洛斯安第斯大学、哥伦比亚大学、美国蒙大拿州立大学和爱达荷国家实验室、萨尔瓦多大学和巴西巴伊亚州立大学合著的论文《Prevalence, Common Causes and Effects of Technical Debt: Results from a Family of Surveys with the IT Industry》 调查了 12 个国家/地区的研究人员的反馈，研究各种软件开发活动与技术债（Technical Debt，简称 TD）之间的关系。发现：TD 的主要影响是交付延迟，可维护性低，和返工；导致 TD 的 8 大原因最大的是 Deadline；TD 类型占比 TOP5 是设计、测试、代码、架构和⽂档。

TD 类型

• 设计债 (21.99%)：是指违反良好设计原则和实践。 这种欠债可以通过分析源代码来发现。 例如，使用代码审查技术或静态代码分析工具。
• 测试债 (19.94%)：是指与测试问题。 例如，未执行的计划测试或低测试覆盖率。
• 代码债 (14.66%)：是指在源代码中发现的对代码的可读性和可维护性产生负面影响的问题。 例如，过于复杂的方法或不存在的编码标准。 为了消除代码债，需要进行代码重构。
• 架构债 (10.70%)：是指影响架构要求（例如，性能、可维护性、健壮性等）的系统架构问题。 例如，违反模块化原则或分离不佳会导致系统的进一步演进、维护和扩展出现重大问题。
• 文档债 (9.09%)：是指在软件项目的文档中发现的问题，包括文档缺失。 它是通过查找不一致、缺失、不充分或不完整的文档来发现。 例如，技术文档已过时，无法反映系统的实际状态。
• 需求债 (8.80%)：是指约定的需求与软件产品中实际实现的需求之间的差距。 例如，这可以表现为部分实现的要求或仅针对某些情况定制的要求。
• 流程债 (4.11%)：是指低效流程。 例如，随着时间的推移，流程发生了变化，现有的做法不再有效。
• 基础设施债 (2.93%)：是指如果存在于组织中会显着降低团队交付优质产品的基础设施问题。 例如，使用过时的工具或推迟定期软件或系统更新。
• 缺陷债 (2.79%)：是指发现的已知缺陷，但修复被推迟或从未修复。 推迟修复的决定可以在系统中积累大量的 TD。
• 人力债（1.32%)：是指与人有关的问题。 例如，缺乏需要额外培训或特定技能和知识。 与人相关的问题要复杂得多，它们涉及直接影响生产力和人们满意度的社会组织因素。

导致 TD 的 8 大原因

结论：

• Deadline、未采用良好做法、缺乏经验和压力是招致 TD 的最可能原因。这些原因很可能是计划不当、缺乏明确定义的流程或无效的项目管理。
• 基础设施原因最有可能导致架构债，而导致构建或可用性债的可能性较小。开发问题原因更有可能导致代码或设计债，但不太可能导致测试债。外部因素更容易导致基础设施债。 规划和 管理和方法原因更容易导致测试债。

8 大原因：

1. 规划和管理：同时处理不同的客户和项目、行为不当、领导不力。
2. 开发问题：缺乏质量、遗留系统、遗留工件。
3. 方法论：未执行测试，任务分配不佳。
4. 缺乏知识：缺乏经验、上下文。
5. 人：过度自信，不分享知识，缺乏团队沟通。
6. 组织：缺乏培训，项目缺乏优先级。
7. 外部因素：付款动态、停产的依赖。
8. 基础设施：技术、工具、平台选择不足，所需基础设施不可用。

TD 的影响

结论：

• TD 的存在最有可能导致交付延迟、可维护性低并产生返工需求。 这些影响还会导致长期影响，最有可能造成经济损失。
• TD 的代码和测试类型可能分别导致内部和外部质量问题。 同时，需求债很可能导致规划和管理问题。 此外，缺陷债与人相关的问题有关。

6 大影响：

1. 规划与管理：增加成本，增加投入。
2. 外部质量：低质量、低性能、低可维护性。
3. 内部质量：代码可读性差，维护量增加。
4. 人：客户或用户不满意，缺乏知识。
5. 开发问题：代码重用率低，易处理性低。
6. 组织：财务损失，公司形象受损。

References

• We invested 10% to pay back tech debt; Here’s what happened
• How to Best Use MTT* Metrics to Optimize Your Incident Response