技术债务是一个很出名的概念，它是在1992年由沃德•坎宁安（Ward Cunningham）（wiki创始人）提出的，他在最近的视频中谈到了这个话题。从那时以来，在博客以及文章上，这个话题被讨论和研究了无数次。在这里我不能描述它的很多细节，但我可以推荐你去阅读那些被认为是在这个主题之下的相关文章，比如：Martin Fowler。这里摘录了一篇文章，通过比喻给出了一个的观点：

在这个比喻中，我们通过临时应急的方式设置了一个技术债务，它类似于经济上的债务。就像经济上的债务，技术上的债务也是要付利息的，它存在于我们将来的开发上，因为选择了临时的应急措施，在某个时候，我们将会付出某种形式的额外代价。我们可以选择继续付利息，或者我们可以选择通过重构过去的临时处理方案，直接支付本金，获取更好的设计。虽然它当场支付掉了本金，却可以让我们在未来减少利息上的支出。

这个比喻看起来已经被许多开发者接受了，并且每天还有许多人在推特上讨论关于临时措施带来的技术债务。但是除了这个概念，是时候回到评估偿还上来了，没有哪篇文章介绍如何计算债务或者去计算债务的方法。这类似于借钱去买了一个房子，但是2年之后却没有办法知道剩余的债务，以及每个月要还多少利息:-)。

通过Martin Fowler的描述，开发者很明智，并且许多时候会做出深思熟虑的选择去借取——为了买时间。当开始一个新的开发，正如你所知道，正好是技术债务......为0的时候。但是，当扩展或者维护一个遗留的程序时，那就是另外一个故事了，没有人知道它确切地历史欠账。当一个开发者没有遵循最佳的实践方法的时候，你可能没有意识到，你就已经借了钱了。那就是为什么，评估大致的技术债务是非常有用的。

在介绍Sonar插件之前，这里有一些有趣的和相关的概念要介绍：

• 在维护一个应用时，每次你添加或者改动一行代码，却没有任何的单元测试就类似于借钱
• 跳过设计阶段就类似于借钱去获取一个非常“快速”和“可预期”的投资回报
• 重构就类似于偿还掉本金
• 当利息上涨时，开发效率降低
• 管理者不重视代码质量，就问问他们关于偿还的债务问题，让他们重视起来
• 破产是一个在技术债务逻辑上的扩展，指的是在技术债务上失去了控制......我们称之为系统重写

当讨论源代码质量的时候，我喜欢谈谈这里的七宗罪，每一个都代表质量分析上的主要问题：不均匀分布的复杂性，重复代码，缺乏注释，违背代码规范，潜在的bug，没有单元测试或者无效的代码和糟糕的设计。你已经知道，Sonar实际上覆盖了它们中的6种类型，除此之外的1/7（糟糕的设计）可能也开始摇晃了:-)它被覆盖那只是时间的问题。

从这个观察来看，为了得到在各方面都完美分数，我们决定建立新的量化指标反映到底有多少的工作量是需要的。换言之，就是在一个项目中每一笔债务偿还的成本。通过汇总结果，我们获得了一项全面的指标，在我们的报告中使用了$符号来保持它的趣味性！连同这个指标在内，每个指标都被重新分配，也就是说，每个指标有多少（份额）被分配进技术债务中。

当前插件的版本是0.2，并且可以使用下面的表达式去计算债务 :

条件:

通过计算这种方式， 它可以接近实际中的情况，技术债务的量化（测定）是宝贵的:

• 在项目，模块（等等）上，它是一项综合的指标
• 它可以在时间上被跟踪（历史数据，趋势）
• 它可以让众多项目进行比较
• 他可以被深度探讨，甚至可以......

作为第一个版本，你可能要被提示选择一些选项，为了插件的配置可以更灵活地被调整，付出一些是值得的。

插件已经被安装在Nemo中，作为Sonar的公开实例，现在有超过80个开源项目被计算了债务。插件仅仅依赖于有效的Sonar扩展点上，并且是能通过Sonar计算的高水平量化案例。

今天，我将停下我讲述技术债务的脚步，但还是想简单地提一下我们后续计划要添加的东西：利息，负债比率和项目风险概况。我确信你想要知道你自己项目中的技术债务......那么，我希望你现在就回到Sonar这个话题，去安装这个新插件。