技术负债（Technical Debt），也叫设计负债（Code debt）或 代码负债（code debt） 是用来描述，在软件开发过程中，为了满足超量的开发需求，使用临时简便的解决方法，取代全面解决方案，所带来的问题。
与金融负债一样，技术负债也会产生和积累利息，导致后继的开发和变更更加困难。没有偿还的技术负载会增加“软件熵（Software entorpy）"。
技术负载的产生
技术负债产生的原因包括以下方面（看看我们中几枪）：
- 业务压力
为了满足业务的快速要求，在必要的修改并没有完成时就匆匆发布，这些未完成的修改形成技术负债。 - 缺少过程和理解
业务人员不清楚不理解技术负债的概念，在决策时不考虑其带来的影响。 - 模块之间解耦不够
功能没有模块化，软件柔性不够，不足适应业务变化的要求。 - 缺少配套的测试
导致鼓励快速而风险很大的“创可贴”式的BUG修复。 - 缺少文档
只有代码没有必要的支撑文档。 - 缺少协作
组织中的知识共享和业务效率低，或者初级开发者缺少必要的指导 - 并行开发
同时在并行的多个分支最终需要进行合并，如果过多的修改在独立进行，可能会形成技术负债。 - 重构延迟
在开发的过程中，某些部分的代码会变得难以控制，这时候就需要进行重构，以适应将来的需求变化。重构越是推迟，这些已有的代码被使用的越多，形成的技术负债就越多，直到重构完成。 - 不遵循标准
忽略已有的业界标准、框架和技术。最终都会需要与现有的系统进行整合，越早做，影响越小。 - 缺少技能
有时，开发者确实只是不知道如何编写优雅的代码。 - 缺失所有者(Lack of ownership)
在软件外包时会发生，有时需要对外包出去的代码重构。 - 技术领导能力差
糟糕的命令传达下去只会增加技术负载，而不是减少。 - 最后时刻的变更（Last minute specification changes)
这些变更有可能影响到整个项目，但却没有时间或预算进行确认。
技术负债的类型
Folwer 在 TechnicalDebtQuadrant 一文中，根据“鲁莽-谨慎”和“故意-无意”两个维度对技术负载进行了分类：
- 鲁莽而故意的技术负债
团队没有时间做设计，仅给出一个匆忙做出的方案，缺乏对质量的预见； - 谨慎而故意的技术负债
尽管有很多已知的缺陷，但团队必须现在就交付，同时对造成的后果心中有数； - 鲁莽而无意的技术负债
团队压根就不知道基本的设计原则，更不用说故意引入了； - 谨慎而无意的技术负债
那些拥有优秀设计师的团队很容易遇到这种情况。他们交付的方案具有商业价值，但在完成方案后才明白什么才是最好的方案。
技术负债的偿还
技术负债必须及时偿还。一个有能力的技术团队应该承担更多的第二种（谨慎而故意）类型的技术负载，并且非常清楚自己的偿还能力。这些行动包括：
- 对技术架构重新的梳理
对于没有及时进行模块划分的功能进行梳理，使之符合整体的设计原则； - 对关键代码的重构
对即将失去控制的模块代码重构，以适应未来需求的变化； - 新技术的引入
采用更加适合的技术取代临时的解决方案 - 补充文档
对缺失的必要的支持文档进行补充完善 - 加强测试
对于未能覆盖的功能补充测试 - 加强人员培训
提升人员的开发能力，包括补充人员。注意，给一个交付压力巨大的团队增加新人，是在火上浇油，是在增加技术负债而不是减少技术负债。 - 提升技术管理能力
对有问题的技术决策和管理流程进行优化，提升开发的纪律
技术负债的后果
技术负载并不是一件坏事，事实上，适度的技术负债是快速推动业务发展的保障。就如同金融行业鼓励大家使用信用卡一样，适度的技术负债是信誉和技术能力的体现。一个成熟的团队能够非常清楚自己的技术负债，并且具有很强的偿还能力，可以很快从巨大的交付压力中恢复。但一个新的团队，盲目的增加技术负债是非常危险的一件事情。缺少经验和能力，无法准确评估自己的债务和偿还能力，很容易导致失控。
如同金融负债一样，技术负债会产生利息，并且这个利息会越滚越多，甚至最后都无法计算其带来的影响。将承担着技术负债的代码发布到生产系统，就是提升负债的利率。
技术负债是造成发布延期，项目进度失控的一个重要原因。当发现延期越来越多，质量越来越不可控，就意味着技术负债已经带来很大影响。开发人员花的大量工作是在偿还技术负债带来的利息，而不是有效生产。
一味要求技术团队赶进度，都是2，3天之后就要求功能上线，是在透支使用技术团队。长此以往，将会导致技术团队破产。轻则系统失控，任何一点小的功能都会导致无可预知的问题，质量无法保障，运营成本剧增。重则丧失品牌信誉，甚至导致法律纠纷，错失市场机会。
网友评论