技术债：千里之堤毁于蚁穴

最近读了一篇论文《Prevalence, Common Causes and Effects of Technical Debt: Results from a Family of Surveys with the IT Industry》，论文很长，主要是通过调研了12个国家和地区的开发人员，给出一些技术债务的分析。

在软件开发组织中平均有25%的成本浪费于解决技术债遗留的问题。

被调查系统的信息分类

参与调研的项目从如上几个纬度做了一些分类：系统服务年限，开发模式（敏捷、瀑布、混合），系统的规模（以MLOC为单位），团队规模具体如上图，从文章可以看出调研的覆盖范围还是很全面的。

是什么原因引起了技术债

如上是对于不同技术债的分类和占比统计，文中对于技术划分详细：

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

如上引起技术债的原因，其中包含了8个纬度：

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

技术债束之高阁，视而不见的恶果

技术债的影响如上图所示，主要分成了6大类主要的影响：

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

结论

从分析上可以看出技术债是由于各种细节的原因导致的，但是如果将系统的技术债务束之高阁、视而不见，那么小问题不断的积累，最终就会变成难以解决的大问题。在软件开发组织中平均有25%的成本浪费于解决技术债遗留的问题。这个结论对于任何一个公司的领导都不能视而不见。