短期加速了软件开发，但是在未来给自己带来了额外的负担，这种技术负债的情况比比皆是，今天来说说技术负债的问题。

1.什么叫技术负债？

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

1992年，沃德·坎宁安首次将技术的复杂比作为负债。

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

2.技术负债产生的原因是什么？

很严重的债务体现在架构或是平台技术方面犯了一个基础的错误，没有选择，也没有足够的时间来正确重写。这些错误体现在

无法扩展，可靠性低；

非常难维护；

次之的债务体现在 容易出错的代码 – 80%的错误出现在20%的代码中。

一般的债务体现在

不容易进行系统测试 – 增加了测试的开销，也无法及时发现代码质量问题。

不注意打包、发布和部署。太过依赖手动测试，很容易在代码上线的时候造成错误。就像测试一样，发布和部署带来的开销不会消失，会逐渐的增加。

团队成员不能理解的关键代码

向前向后的兼容性。这是必须的和短期的债务。需要维护这些兼容版本的时间越长，代价会越大。

库和中间件过期

重复的，复制粘贴的代码。

大家都知道的、很明显的错误，并且没有被修复的缺陷。

低效的设计或构建，过度消耗硬件，使用过多的内存，网络带宽或CPU。

较小的债务体现在

使用编程习惯和模式不一致 – 程序员不理解已经存在的模式，或是不喜欢它们，而引进新的模式，或者仅仅是想改变它们。

没有错误处理和异常处理，或者方法不对。在上线阶段会有一些问题

非常小的债务体现在

硬编码，神秘的数字，代码不遵循规范，混乱的命名，缺失的注释，不整洁的代码。

文档过期 – 文档的内容和实际系统不一致

3.技术负债有哪些负面影响？

如果公司要解决技术负债，花费的成本往往是很高的。

在所调研的系统中，35%的技术债务已经严重影响了系统的支持和维护，它们可能导致安全、性能问题甚至威胁到正常运行。

4.避免技术负债的方法是什么？

注意五大程序质量特征 - 稳定性、性能、安全、可移交性以及可修改性

采用成熟的开发方法比如敏捷开发以提高程序质量，瀑布方法具备“可移交性”和“可修改性”，但不适合目前的开发要求。

系统模块化（Modularity of systems ）可能影响质量和性能。

提高代码和系统的可维护性。

减少代码发布的频率，以减少技术负债。

5.如何评估技术债？

请参考此文，用Sonar 评估你的技术债务- 技术翻译- 开源中国社区 http://www.oschina.net/translate/evaluate-your-technical-debt-with-sonar

当前插件的版本是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

通过计算这种方式， 可以接近实际中的情况，建议经常量化技术债务，因为技术债务可以

是综合的指标，衡量项目和模块的质量

根据历史数据和趋势跟踪

比较多个项目