从传统模式向敏捷模式转变－技术债

2017-01-10 本文已影响0人 lipy_

代码写好就交，意味着欠债的开始。稍微欠点技术债得确可以加快速度，但前提是事后及时重写代码，如果只借不还，后果很危险。在不准确的代码上所花费的每一分钟，都算是技术债的应付利息。不稳固、脆弱的代码实现所引发的债务负担，会使整个工程组织陷入裹足不前的艰难境地。

技术债既指我们有意选择的捷径，又指许多损害软件系统的不良实现。

策略性技术债和低级技术债通常都是迫于业务压力而必须满足某个迫在眉睫的重大最后期限而造成的。

强令团队必须在理想的发布日期交付所有特性。负责干活的团队就会被要求提高效率。按照这种提高的速率工作，团队必须做出慎重的决策，承担技术债。

减少测试既增加债务又减缓速率，因为问题潜伏得越深，越晚发现，修复所花的时间越长。将测试测底融入软件开发过程之后，有经验的团队可以更快的交付高质量的产品、产生的技术债更少。

旧债不还，很快会积累新债。

管理技术债的增长，第一种方法是停止向产品里增加低级债务。使用良好的技术实践是一个非常好的开端。比如简洁设计、TDD、持续集成、自动化测试和重构等。

有些工作本来应该在构建特性就做，结果却拖到后期才做，他们是产生技术债的重要根源。使用Scrum之后，我们希望用一个强完成定义来知道团队在每个冲刺结束时给出一个低负责或零负债的解决方案。

技术债触及并影响到整体经济核算的许多不同层面。如果不考虑最重要的因素，就无法确保正确量化承担技术着所涉及的经济效益。

偿还技术债的五大方式