这是什么
你赶deadline的时候，写了段'能跑就行'的代码，心想'以后再优化'。恭喜，你刚借了一笔'技术债'。就像金融债务一样，技术债也有利息——每次新功能要在这个烂代码上开发，效率都会降低。一开始你觉得没事：'跑得挺快的嘛。'但债务越攒越多，直到有一天：改一个bug冒出三个新bug，加个功能要改20个文件，新人看一眼代码就想离职。这时候你才发现，之前'省下来的时间'，全变成了10倍的利息。沃德·坎宁安（Wiki发明者）创造了这个概念，他说：适当的债务是OK的——就像创业公司借钱加速发展。关键是你要'有意识地借债'，并且有计划地偿还。
什么时候用
评估代码质量时、做'先上线还是先优化'的决策时、项目管理中预留重构时间
什么时候别用
一次性原型或Demo（不需要长期维护的代码不用纠结技术债）；安全关键系统（绝对不能欠债）
怎么用
- 1
识别技术债
哪些代码'能动就不敢改'？哪些模块改一个功能要动10个文件？这就是技术债
- 2
量化债务成本
估算：如果不重构，未来6个月会多花多少开发时间？这就是技术债的'利息'
- 3
区分'好的债'和'坏的债'
为快速验证市场而写的临时代码是'好的债'（有计划还）。因为懒或能力不够写的烂代码是'坏的债'
- 4
预留还债时间
每个迭代周期预留20%的时间来还技术债。就像财务上还债一样，要定期还
真实例子
Twitter的'fail whale'
2007-2010年，Twitter经常显示一只鲸鱼被小鸟吊起来的图片——服务器又崩了。原因是早期为了快速上线，技术架构过于简单，用户暴增后扛不住了。Twitter花了两年时间'还债'——用Scala重写了核心系统，从Ruby on Rails迁移。那两年几乎没有新功能，全在还技术债。
某创业公司的教训
一家电商创业公司为了赶双十一，写了大量'临时'代码。双十一过了，团队说'回头重构'，但业务压力一直没停。两年后代码已经没人敢改了，每次发版都像在拆炸弹。CTO最终花了4个月全面重构，期间所有新需求暂停，业务部门怨声载道。