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