一文带大家了解什么是技术债务

什么是技术债务

技术债务（technical debt），也称为代码债或设计债，是软件开发中的一个术语，用于描述由于最初选择更快的交付而不是需要更长时间的干净，高效的代码而导致的额外返工成本。这个概念是从金融债务中借来的，在金融债务中，一个人借钱去买他现在想要的东西，当你没有钱买它的时候，以后必须支付利息。本质上，它指的是在项目速度上对良好的编码实践所做的妥协，这积累了最终必须以时间、金钱和资源的形式“偿还”的“债务”。

技术债务产生的原因

技术债务通常是在软件开发选择不符合推荐或生产所需的标准时引起的。有一些技术债务基本上是不可避免的，但可以通过代码检查大大减少。其中技术债务产生的原因主要包括

持续发展（ongoing development）

随着公司和代码的不断变化，他们在长期或持续的项目改进中运作，随着时间的推移，旧的解决方案效率低下。

缺乏定义（lack of definition）

如果你没有澄清或建立一个什么是技术债务的基线，或者在开发周期中仍然在建立需求，那么在开始时创建的东西可能不是项目结束时所需要的。

经营压力（bussiness）

随着企业试图维持运营并保持竞争力和财务繁荣的持续压力，他们可能会发布或生产一些尚未完全准备好的东西，以便将其发布或成为该领域的第一人。

缺乏技术知识或理解（Lack of technical knowledge or comprehension）

即使是真正精明的商业人士也可能不知道技术债务，并且对他们在专注于产品和底线的同时努力推出和发布更新时出现的并发症视而不见。

软件模块的耦合（Coupling of software modules）

软件功能之间的相互依赖程度不独立于可互换的模块，并且不能适应不断变化的业务需求。

缺乏测试或验证套件（The lack of a test or validation suite）

为了快速上线缺乏充分的测试

缺乏协作（Lack of collaboration）

重要的知识在部门、团队成员和个人之间是孤立的，这会因为缺乏沟通、培训和指导而降低业务生产力。

同步发展（Simultaneous development）

在许多组织中，开发团队可能同时在不同的分支上工作，导致当成品合并到单个代码库中时缺乏代码内聚性。

延迟代码重构（Delayed code refactoring）

随着项目开发需求的变化，以前创建的其他代码可能会过时或难以更新以满足未来的编码或业务需求。随着重构被推迟，技术债务变得越大。

没有明确的标准或一致性（No clear standards or alignment）

没有明确的编码标准或一致性，制定标准等待的时间越长，未来的成本就越高。

开发人员知识不足（Insufficient developer knowledge）

开发人员不知道如何创建和执行优雅，干净的代码。

外包软件开发人员（Outsourced software developers）

当资源外包给第三方开发人员时，有时会导致内部开发团队需要重构交付的代码。

有缺陷的领导（Defective leadership）

有缺陷的领导，领导者在让下属执行任务之前没有经过清楚的考虑。

最后一分钟的变化（Last minute changes）

当项目即将完成或接近完成，而新的要求在紧迫的截止日期之前提出，没有时间、资源或预算来测试和收集调整的影响，以正确地做出适当的更改。
 

技术债务的分类

虽然技术债务的类型和定义多种多样，但它们最终可分为三类：无意的、故意的和环境技术债务。

故意的技术债务

可以定义为故意的，战术性的决策，一个人在当时有意识地做出的决定，采用捷径或不太完美的解决方案来追求快速回报。

无意的技术债务
无意的技术债务可以被定义为无意识或不可预见的创建糟糕或草率的编码，主要是指开发人员不知道他们无意中添加到代码中的错误，这些编码在没有适当的测试和审查的情况下被推广到生产环境。

环境技术债务
环境技术债务被定义为随着时间的推移而增加的债务，它独立于软件的内在质量或开发人员的意图，由其他外部因素引起的，并因外部因素的变化而不断积累。例如操作系统更新，导致某些东西损坏或无法正常工作。中断连接的第三方API更新或带来不必要的用户问题的代码库。安全更新或补丁可能会阻止应用程序正常运行。即使原始代码是好的，也会随着时间的推移而逐渐增加。

更细节的技术债务

上面的技术债务说的比较宽泛，那么我们就对其进行细化，细化到在我们工作中可以具体应用的场景，主要包括：

• 架构债务：

产品架构中的问题，这些问题影响了架构需求。一般来说，这种技术债务是由于初始解决方案低于理想，从而损害了内部质量。

• 构建债务：

解决使构建任务变得更困难和不必要的耗时的问题。

• 代码债务：

在源代码中发现的问题（违反最佳实践或编码规则），这些问题会对其可读性产生负面影响，并使其难以维护。

• 缺陷债务：

指已知的缺陷，通常由测试活动或用户识别。开发团队同意纠正它们，但由于优先级竞争和资源有限，它们将被推迟。

• 设计债务：

通过分析源代码和识别违反良好软件设计原则的行为而发现的技术债。

• 文档债务：

这种类型的技术债务发生在开发人员过于匆忙而无法彻底记录他们的代码时，因此没有其他开发人员可以用来理解他们代码的文档线索。

• 基础设施债务：

如果软件组织中存在延迟或阻碍开发活动的基础设施问题，则会导致债务。这样的TD会对团队生产高质量产品的能力产生负面影响。

• 人员债务：

由于员工培训或分配方面未解决的问题而产生的债务。

• 代码版本债务：

源代码版本控制中的问题，例如不必要的代码fork。

• 流程债务：

对低效流程的抱怨，例如（预计的流程可能不合适）。

• 需求债务：

最优需求规范和实际系统实现之间的差距。

• 服务债务：

对不适当的Web服务的拒绝，导致服务功能和应用程序需求之间的不兼容。

• 测试自动化债务：

支持自动化功能测试的工作，以支持持续集成和更快的开发周期。

• 测试债务：

当团队开始花更多的时间在测试维护上，而不是花更少的时间在创建测试上以确保软件没有bug时，就会产生技术债务。

消除技术债务的方法

消除技术债务主要可以通过以下四种方法

1.使用自动化测试工具，例如如SonarQub可以减少或消除技术债务。
2.重构源代码
3.公司应该在内部建立开发人员要遵循和执行的编码标准。
4.通过项目管理工具创建更好的项目结构，或者监控代码问题并在项目中尽快修复它们，将减少债务。

最后的总结

当产品发布的时间对你不利时，或者当重要的软件更新需要立即发布时，接受一点短期的技术债务是合理的。但是我们必须有计划地偿还并完全消除技术债务，否则随着技术债务的持续堆积而形成雪崩，最后应了那句话：“如果没钱可以拿喜儿来抵债！！！”

我的每一篇文章都希望帮助读者解决实际工作中遇到的问题！如果文章帮到了您，劳烦点赞、收藏、转发！您的鼓励是我不断更新文章最大的动力！