技术债务–您实际要花多少钱？

技术债务隐喻背后的想法是，采取捷径（故意技术债务）或犯错误（非故意技术债务）会产生成本，并且不处理这些捷径和错误的成本会随着时间而增加。

这个比喻的问题在于，对于金融债务，我们知道今天还清债务要花费多少，并且我们可以计算出将来必须支付的利息。 技术债务虽然模糊得多。 我们真的不知道我们承担了多少债务-您可能承担了很多无意的技术债务 -您可能仍在不知不觉中继续承担下去。 而且，我们无法量化这实际上使我们付出了多少–到目前为止，我们已支付了多少利息，如果今天不注意的话，将来的总成本可能是多少。

有些人试图将技术债务纳入具体的财务条件 。 例如，根据CAST Software的CRASH报告

“应用程序每行代码平均承担$ 3.61的技术债务”。

由于某种原因，Java应用程序的平均成本甚至更高：每行代码$ 5.42。 这些数字是通过对客户代码进行静态结构分析得出的。

Sonar是一个用于管理代码质量的开源仪表板，它还尝试使用静态分析结果（例如自动测试的代码覆盖率，代码复杂性，重复项，违反编码习惯，注释密度）来计算代码库的技术债务成本 。

以这种方式思考技术债务很有趣，但是我们不要假装这些是我们可以用来做出折衷决策的硬数字。 尽管数字看起来很准确，但它们是任意的，猜猜。 他们认为技术债务可以通过查看代码结构的工具来计算。 不幸的是，处理技术债务并不是那么简单。

但是，如果债务过于模糊而无法用详细的成本术语衡量，那么您如何知道哪种债务对您的伤害最大，如何知道您的债务过多呢？ 让我们看一下使用模糊方法处理的各种技术债务，以及这些技术债务可能给您带来多少费用。

$$$在架构或平台技术上犯了一个根本性的错误–您直到发现真正的客户都在使用该系统之前，才发现为时已晚，例如数据库或消息传递结构等关键技术无法扩展或是不可靠的，或者由于核心依赖性问题而无法按需要扩展架构，或者您对系统的工作方式或客户的使用方式做出了一些根本上不正确的假设。 现在，您别无选择，只能重新启动，或者至少重写系统的大部分内容，以使其正常运行或保持正常运行，并且您没有时间正确执行此操作。

$$-$$$容易出错的代码–发现80％的错误的代码的20％。 Capers Jones表示，所有大型系统都有少量例程，其中会聚集错误和问题，难以理解的代码，更改成本高昂和危险的代码，因为这样做一开始做得不好，或者由于近视修复和更改的积累。 不重写此代码是开发人员犯下的最昂贵的错误之一。

$-$$无法轻松测试系统-因为您没有良好的自动化测试，或者测试脆弱而缓慢，并且在更改代码时会崩溃。 测试成本可能占进行任何更改或修复的成本的一半以上-有时测试可能比进行修复花费更多的时间，且成本要高得多-随着编写更多代码，测试成本会随着时间的流逝而增加，例如系统会添加更多界面和选项。

$-$$不注意打包，发布和部署。 过分地依靠手动步骤和手动检查，导致深夜生产中的错误和问题。 就像测试一样，发布和部署成本不会消失，它们只会不断增加。

$-$$该代码神秘地起作用，但是没有人知道如何或为什么-通常是性能关键或安全关键的低级管道代码，该代码由很早就离开公司的向导编写。 它可能是精美的代码，但是如果团队中没人了解它，那就是定时炸弹–总有一天，有人将不得不对其进行更改，修复或尝试。

$-$$向前和向后兼容性适配器和折衷方案。 这是必要的短期债务。 但是，维护这些折衷方案所需的时间越长，成本就会增加。

$-$$过时的库和中间件堆栈–您在应用补丁和升级方面落伍了。 即使您现在拥有的代码是稳定的，也存在未修补安全漏洞的风险。 持续的时间越长，您所处的位置就越远，风险就越高–在某个时候，如果不再支持该软件或该软件不再受支持，您的手就会被召唤。

$-$$复制，复制和粘贴代码。 这是技术债务和静态分析工具的缺陷之一。 几乎每个人都有。 但是真的有多糟吗？ 成本取决于开发人员制作了多少个克隆，需要多长时间更改一次克隆，不同副本之间有多少细微差别，以及查找副本并跟踪它们的难易程度。 如果制作副本的开发人员仍在团队中，并且能够很好地跟踪所有副本，那么花费不多。

$-$$代码中已知的，突出的错误以及未解决的静态分析结果。 成本和风险取决于您拥有多少错误和警告，以及它们是否令人讨厌。 但是，如果它们是真正的问题，那么现在应该已经解决了。 如果不给任何人打扰，一个错误真的是一个错误吗？

$-$$设计或实现效率低下，“将硬件投入其中”，使用了过多的内存，网络带宽或CPU。 硬件很便宜，但是随着扩展，这些成本可能会增加很多。

$编程习惯用法和模式的用法不一致–开发人员要么不了解现有模式，要么不喜欢它们并引入了新的模式，或者不在乎，只是想完成他们的更改。 这很丑陋，并且可能使开发人员感到沮丧。 但是，与这种情况一起生活的实际成本通常比试图将其全部清除的成本要少。

$错误处理和异常处理的缺失或不良。 它会在生产中不断咬你，但是至少要花大价钱才能花很多钱。

$ 0.01硬编码，魔术数字，不符合标准的代码，元素命名不正确，缺少注释以及需要整理的代码。 这是痛苦的事情，但是作为标准重构工作的一部分，这种事情很容易清理。

$ 0.01过时文档–技术债务中通常考虑的另一个问题。 但是说实话， 大多数程序员还是不会阅读文档 。 如果没有人使用它，请摆脱它。 如果人们在使用它，为什么它不是最新的？

$ 0.00可以使用内置语言功能或库，现有框架或常用服务完成的手工滚动代码。 当有人意识到它时，这是令人失望的，但是除非这段手工编写的代码中包含很多错误，否则这是沉没的成本，而不是随着时间的推移而增加的成本。

债务种类不同，成本也不同。 弄清楚您的实际成本在哪里以及如何处理，并不容易。

参考： 技术债务–您实际要花多少钱？ 来自我们的JCG合作伙伴   Building Real Software博客上的Jim Bird。

翻译自: https://www.javacodegeeks.com/2012/02/technical-debt-how-much-is-it-really.html