开源中国 Sonar 代码质量管理系统 —— http://sonar.oschina.net/
技术债务是一个很出名的概念，它是在1992年由沃德•坎宁安（Ward Cunningham）（wiki创始人）提出的，他在最近的视频中谈到了这个话题。从那时以来，在博客以及文章上，这个话题被讨论和研究了无数次。在这里我不能描述它的很多细节，但我可以推荐你去阅读那些被认为是在这个主题之下的相关文章，比如：Martin Fowler。这里摘录了一篇文章，通过比喻给出了一个的观点：
在这个比喻中，我们通过临时应急的方式 设置了一个技术债务，它类似于经济上的债务。就像经济上的债务，技术上的债务也是要付利息的，它存在于我们将来的开发上，因为选择了临时的应急措施，在某 个时候，我们将会付出某种形式的额外代价。我们可以选择继续付利息，或者我们可以选择通过重构过去的临时处理方案，直接支付本金，获取更好的设计。虽然它 当场支付掉了本金，却可以让我们在未来减少利息上的支出。
这个比喻看起来已经被许多开发者接受了，并且每天还有许多人在推特上讨论关于临时措施带来的技术债务。但是除了这个概念，是时候回到评估偿还上来了，没有 哪篇文章介绍如何计算债务或者去计算债务的方法。这类似于借钱去买了一个房子，但是2年之后却没有办法知道剩余的债务，以及每个月要还多少利息:-)。
通过Martin Fowler的描述，开发者很明智，并且许多时候会做出深思熟虑的选择去借取——为了买时间。当 开始一个新的开发，正如你所知道，正好是技术债务……为0的时候。但是，当扩展或者维护一个遗留的程序时，那就是另外一个故事了，没有人知道它确 切地历史欠账。当一个开发者没有遵循最佳的实践方法的时候，你可能没有意识到，你就已经借了钱了。那就是为什么，评估大致的技术债务是非常有用的。
在介绍Sonar插件之前，这里有一些有趣的和相关的概念要介绍：
- 在维护一个应用时，每次你添加或者改动一行代码，却没有任何的单元测试就类似于借钱
- 跳过设计阶段就类似于借钱去获取一个非常“快速”和“可预期”的投资回报
- 重构就类似于偿还掉本金
- 当利息上涨时，开发效率降低
- 管理者不重视代码质量，就问问他们关于偿还的债务问题，让他们重视起来
- 破产是一个在技术债务逻辑上的扩展，指的是在技术债务上失去了控制……我们称之为系统重写
当讨论源代码质量的时候，我喜欢谈谈这里的七宗罪，每一个都代表质量分析上的主要问题：不均匀分布的复杂性，重复代码，缺乏注释，违背代码规范，潜 在的bug，没有单元测试或者无效的代码和糟糕的设计。你已经知道，Sonar实际上覆盖了它们中的6种类型，除此之外的1/7（糟糕的设计）可能也开始 摇晃了:-)它被覆盖那只是时间的问题。
从这个观察来看，为了得到在各方面都完美分数，我们决定建立新的量化指标反映到底有多少的工作 量是需要的。换言之，就是在一个项目中每一笔债务偿还的成本。通过汇总结果，我们获得了一项全面的指标，在我们的报告中使用了$符号来保持它的趣味性！连 同这个指标在内，每个指标都被重新分配，也就是说，每个指标有多少（份额）被分配进技术债务中。
当前插件的版本是0.2，并且可以使用下面的表达式去计算债务 :
| Debt(in man days) = | cost_to_fix_duplications + cost_to_fix_violations + |
| cost_to_comment_public_API + cost_to_fix_uncovered_complexity + | |
| cost_to_bring_complexity_below_threshold |
条件:
| Duplications | = | cost_to_fix_one_block * duplicated_blocks |
| Violations | = | cost_to fix_one_violation * mandatory_violations |
| Comments | = | cost_to_comment_one_API * public_undocumented_api |
| Coverage | = | cost_to_cover_one_of_complexity * uncovered_complexity_by_tests (80% of coverage is the objective) |
| Complexity | = | cost_to_split_a_method * (function_complexity_distribution >= 8) + cost_to_split_a_class * (class_complexity_distribution >= 60) |
通过计算这种方式， 它可以接近实际中的情况，技术债务的量化（测定）是宝贵的:
- 在项目，模块（等等）上，它是一项综合的指标
- 它可以在时间上被跟踪（历史数据，趋势）
- 它可以让众多项目进行比较
- 他可以被深度探讨，甚至可以……
作为第一个版本，你可能要被提示选择一些选项，为了插件的配置可以更灵活地被调整，付出一些是值得的。
评论