技术债务是一个很出名的概念，它是在1992年由沃德•坎宁安（Ward Cunningham）（wiki创始人）提出的，他在最近的视频中谈到了这个话题。从那时以来，在博客以及文章上，这个话题被讨论和研究了无数次。在这里我不能描述它的很多细节，但我可以推荐你去阅读那些被认为是在这个主题之下的相关文章，比如：Martin Fowler。这里摘录了一篇文章，通过比喻给出了一个的观点： 在这个比喻中，我们通过临时应急的方式设置了一个技术债务，它类似于经济上的债务。就像经济上的债务，技术上的债务也是要付利息的，它存在于我们将来的开发上，因为选择了临时的应急措施，在某个时候，我们将会付出某种形式的额外代价。我们可以选择继续付利息，或者我们可以选择通过重构过去的临时处理方案，直接支付本金，获取更好的设计。虽然它当场支付掉了本金，却可以让我们在未来减少利息上的支出。 这个比喻看起来已经被许多开发者接受了，并且每天还有许多人在推特上讨论关于临时措施带来的技术债务。但是除了这个概念，是时候回到评估偿还上来了，没有哪篇文章介绍如何计算债务或者去计算债务的方法。这类似于借钱去买了一个房子，但是2年之后却没有办法知道剩余的债务，以及每个月要还多少利息:-)。
通过Martin Fowler的描述，开发者很明智，并且许多时候会做出深思熟虑的选择去借取——为了买时间。当开始一个新的开发，正如你所知道，正好是技术债务......为0的时候。但是，当扩展或者维护一个遗留的程序时，那就是另外一个故事了，没有人知道它确切地历史欠账。当一个开发者没有遵循最佳的实践方法的时候，你可能没有意识到，你就已经借了钱了。那就是为什么，评估大致的技术债务是非常有用的。 在介绍Sonar插件之前，这里有一些有趣的和相关的概念要介绍：
当讨论源代码质量的时候，我喜欢谈谈这里的七宗罪，每一个都代表质量分析上的主要问题：不均匀分布的复杂性，重复代码，缺乏注释，违背代码规范，潜在的bug，没有单元测试或者无效的代码和糟糕的设计。你已经知道，Sonar实际上覆盖了它们中的6种类型，除此之外的1/7（糟糕的设计）可能也开始摇晃了:-)它被覆盖那只是时间的问题。 从这个观察来看，为了得到在各方面都完美分数，我们决定建立新的量化指标反映到底有多少的工作量是需要的。换言之，就是在一个项目中每一笔债务偿还的成本。通过汇总结果，我们获得了一项全面的指标，在我们的报告中使用了$符号来保持它的趣味性！连同这个指标在内，每个指标都被重新分配，也就是说，每个指标有多少（份额）被分配进技术债务中。
当前插件的版本是0.2，并且可以使用下面的表达式去计算债务 :
通过计算这种方式， 它可以接近实际中的情况，技术债务的量化（测定）是宝贵的:
作为第一个版本，你可能要被提示选择一些选项，为了插件的配置可以更灵活地被调整，付出一些是值得的。 |
