技术债务，你理解对了么

 
技术债务（technical debt）是一个把抽象问题形象化的精妙词汇，现在和敏捷沾点边的人都会时不时提到这个词。有时候，普及率高的未见得准确率高。我今天想说的还就是这个技术债务，因为大多数人，都错了。

 债务是什么？是为了追赶进度将代码的一通写草率并对bug假装看不见？还债就是拿出时间去优化我们的代码并修复Bug？如果你这么理解，那绝对大错特错，它很有可能会最终毁掉你负责的软件系统

  Wiki的开发者，也是敏捷宣言参与者之一，今年71岁的Ward Cunningham是首先提出这个概念的人。这位被尊称为“美国程序员”的人，是位极其聪明善于思考的模范码农，“技术债务”的理念就是他多年前（1992年）用Smalltalk开发一款金融软件产品时提出来的。当时客户和团队没有100%理解产品应具备的功能以及应用场景，他用“债务”这个比喻和老板沟通，建议先将不完美的软件送到用户手中，用户看到错误的东西才更容易知道自己需要的是什么。在使用中，团队通过收集反馈提升能力，不断完善产品。

 这里讲的“债务”是本身能力的欠缺造成的，还债就是将通过反馈得到的知识用来弥补产品的不足。优秀是一种习惯，任何时候都应该交付尽你能力写出的最好代码，发布的软件都应该是足够努力的成果，经过充分测试，清除所能发现Bug的程序。绝不应该打着借债的旗号，放任有点难度的Bug，打着赶进度的由头，写出一堆乌烟瘴气的代码。这样做的后果将彻底摧毁所谓的敏捷能力。Bug和烂码并不是“技术债务”，它们仅能算职业素质的低下和责任心的匮乏。

    Cunningham应该是一位善于沟通的人，他用借钱（债）办事的例子，让老板理解尽早将不那么完美的软件送到用户手中的必要性。而这个隐喻的绝妙之处在“利息”，借债办事固然好，但如果没有把学到的东西用于完善产品，那就是借债不还，持续滚动的利息最终会让你的信用卡支付能力清零。想象一下，你不断交付新的代码，但从来不涉及已经发布的程序，这样的后果会是什么？
 技术债务的精髓就是用不完美的产品换知识，将有欠缺的代码（不是一堆烂码且无视Bug）尽快交到用户手中换取反馈，通过不断的重构偿还债务。这样，才能让我们更快的趋于完美。

    Cunningham
曾很无奈的说，他看了许多关于技术债务的解释，基本都偏离了他的初衷。所有的圈子都有歪嘴和尚，
CMMI
如此，敏捷亦如此。