概述
代码写好就交，意味着欠债的开始。稍微欠点技术债得确可以加快速度，但前提是事后及时重写代码，如果只借不还，后果很危险。在不准确的代码上所花费的每一分钟，都算是技术债的应付利息。不稳定、脆弱的代码实现所引发的债务负担，会使整个工程组织陷入裹足不前的艰难境地。
-
团队和组织在深入了解业务领域的同时，还要注意偿还技术债;
-
系统的设计和实现需要跟进以便更好地运用这些认知。
技术债既指我们有意选择的捷径，又指许多损害软件系统的不良实践。 -
不合适的设计：因为当前所用技术或业务发生重大改变，我们之前有效的设计变得不再适用。
-
缺陷：我们已知但没时间解决的软件中的问题。
-
测试覆盖不充分：有些地方我们明明知道该怎么做更多测试但是没有做
-
手工测试过多：实际该做自动化测试的时候我们还在做手工测试。
-
集成和版本管理不善：在做集成和版本管理的时候，采用的方式既费时又容易出错。
-
缺乏平台经验：例如需要某个技术，但是相关人员却不多。
技术债的后果
爆发点不可预测
技术债有一个特性就是不可预测的非线性方式增长。在原有债务基础上增加任何一点技术债，都会产生显著的危害，远远超过新技术债自身的隐含的危害。
交付时间延长
承担技术债意味着现在向未来申请借用工作时间。今天的债务越多，明天的速率就越慢。
缺陷数量多
技术债务状况严重的产品变得越来越复杂，因而也更难把事情做对。
开发和支持成本上升
技术债一增加，开发和支持成本也会开始增加。过去一直简单又便宜，现在变得复杂又昂贵。
产品萎缩
如果对老产品停止增加新特性或修复缺陷使其焕发活力，它对当前或潜在客户就会变得越来越没有吸引力。最后导致产品开始萎缩，不再是大多数客户愿意考虑的方案。
可预测性降低
如果产品确实已经债台高筑，基本上不太可能进行任何形式的预测了。
表现越来越差
技术债越来越多，人们预计工作表现越来越差，进而降低他们对结果的期望。
挫折感四处弥漫
客户满意度降低
技术债的起因
如期完成工作
策略性技术债和低级技术债通常都是迫于业务压力而必须满足某个迫在眉睫的重大最后期限而造成的。
试图以错误的方式提高速率
如期完工的可能性比较小的情况下，负责干活的团队就会被要求提高速率，争取在理想发布日期前完成所有特性。按照这种提高速率工作，团队必须慎重决策，承担技术债。
误区：减少测试可以提高速率
现实的是减少测试即增加债务又减少速率，因为问题潜伏得很深，越晚发现，修复所花的时间越长。
误区：债累债
旧债如果不还，很快会累计新债。如果一直延续下去，有效速率会趋于零的程度。一旦发现深陷技术债务危机，所有的选择都是退而求其次的难难选择。
技术债必须加以管理
技术债和财务债一样，必须管理。没有哪个产品能够做到无债一身轻，认识到这一点也很重要，鉴于此，也不建议努力达到无债状态。即使如此，达到无债状态的经济理由也不够充分。技术债的管理要求综合考量技术和业务因素。
管理应计技术债
使用良好的技术实践
管理技术债务的增长，第一种方法是停止向产品增加低级债务。使用良好的技术实践是一个非常好的开端。
对于积累下来的技术债，代码重构是一个非常重要的减轻债务的工具。重构用于改变既有代码主体的一种技术，在不改变软件外在前提下调整其内部结构。
使用强完成定义
有些工作本来应该在构建特性的时候就去做，结果却拖到后期才做，它们是产生技术债的重要根源。我们希望用一个强完成定义来指导团队在每个冲刺结束时给出一个低负债或零负债的解决方案。
正确理解技术债经济
为了有计划地改善技术债，我们必须正确理解它是如何影响决策的经济考量的。
让技术债可见
让技术债在业务层面可见
让业务人员看见产品的技术债状态很关键。
让技术债在技术层面可见
- 缺陷跟踪系统
- 产品列表里
- 技术债列表
偿还技术债
并非所有的技术债务都应偿还
- 行将就木的产品
- 一次性原型
- 短命产品
网友评论