技术债务（Technical debt）的产生原因及衡量解决

第一次发布代码，就好比借了一笔钱。只要通过不断重写来偿还债务，小额负债可以加速开发。但久未偿还债务会引发危险。复用马马虎虎的代码，类似于负债的利息。整个部门有可能因为松散的实现，不完全的面向对象的设计或其他诸如此类的负债而陷入窘境。 ---维基百科

简介

技术负债（英语：Technical debt），又译技术债，也称为设计负债（design debt）、代码负债（code debt），是编程及软件工程中的一个比喻。指开发人员为了加速软件开发，在应该采用最佳方案时进行了妥协，改用了短期内能加速软件开发的方案，从而在未来给自己带来的额外开发负担。这种技术上的选择，就像一笔债务一样，虽然眼前看起来可以得到好处，但必须在未来偿还。软件工程师必须付出额外的时间和精力持续修复之前的妥协所造成的问题及副作用，或是进行重构，把架构改善为最佳实现方式。
1992年，沃德·坎宁安首次将技术的复杂比作为负债。 ---维基百科

通俗易懂的例子：
技术债务类似于金融债务。软件开发就像是去“贷款”，而技术债务就像是它的“利息”，“利息”是需要以未来额外的时间来还的。重构才相当于是支付“本金”。

技术负债的产生原因

业务压力：为了满足业务的快速要求，在必要的修改并没有完成时就匆匆发布，这些未完成的修改就形成了技术负债。
缺少过程和理解：业务人员不清楚不理解技术负债的概念，在决策时就不会考虑到其带来的影响。
模块之间解耦不够：功能没有模块化，软件柔性不够，不足适应业务变化的要求。
缺少配套的自动化测试：导致鼓励快速而风险很大的“创可贴”式的BUG修复。
缺少必要文档：需求和代码都没有必要的支撑性文档或注释。
缺少协作：组织中的知识共享和业务效率较低，或者初级开发者缺少必要的指导。
重构延迟：在开发的过程中，某些部分的代码会变得难以控制，这时候就需要进行重构，以适应将来的需求变化。重构越是推迟，这些已有的代码被使用的越多，形成的技术负债就越多，直到重构完成。
不遵循标准或最佳实践：忽略了已有的业界标准、框架、技术和最佳实践。
缺少相关技能：开发人员有时候技能缺失，并不知道如何编写优雅的代码。

技术债务的危害

技术负债的“利息”会越滚越多，甚至最后都无法计算其带来的影响。将有技术负债的代码发布到生产系统，就是提高了“利息”的“利率”。最终将会导致技术团队破产，质量无法保障。

技术债务衡量（SQALE & SonarQube）

SQALE (Software Quality Assessment based on Lifecycle Expectations) is a method to support the evaluation of a software application source code. It is a generic method, independent of the language and source code analysis tools. ---wikipedia

SQALE（基于生命周期期望的软件质量评估）是一种支持软件应用程序源代码评估的方法。它是一种通用方法，独立于语言和源代码分析工具。

SonarQube 中的技术债务就是基于SQALE方法，是通过代码规则和问题来实现的。

SonarQube 项目技术债务
-w1348