Technical debt 您如何估计清算技术债务的投资回报率？

我目前使用的是一个相当老的产品，它在过去由于程序员和开发实践的不好而背负了很多技术债务。我们正在开始好转，技术债务的产生已经大大放缓

我已经确定了应用程序中状态不佳的区域，并且我可以估计修复这些区域的成本，但是我很难估计投资回报率（ROI）

代码将更易于维护，并且在将来更易于扩展，但是我如何才能在这些代码上加上一个美元数字呢

一个好的开始看起来像是回到我们的bug跟踪系统，并根据bug和与这些“坏”区域相关的特性估算成本。但这似乎很耗时，而且可能不是价值的最佳预测指标

---

过去有没有人做过这样的分析，有什么建议给我？

经理关心的是通过增长（首先是吸引新客户的新功能）和（第二）优化流程生命周期来赚取美元

从你的问题来看，你的建议属于第二类：这无疑会落后于目标1（因此，如果这样做可以省钱的话，甚至会优先考虑，，因为省钱意味着花钱（至少在大多数情况下；-））

现在，在“技术坏账”上增加一个美元的数字可以转变为一个更积极的旋转（假设以下情况适用于您的情况）：“如果我们投资改造组件X，我们可以更快地引入功能Y，从而获得更多的客户”

---

换句话说，根据失去的商业机会成本评估技术债务成本

我认为你的思路是对的

我不必计算这些，但我与一位朋友进行了一些讨论，他管理着一家大型软件开发组织，拥有大量遗留代码

我们讨论过的一件事是通过分析VCS提交生成一些粗略的工作度量，并使用它们划分程序员小时的粗略估计。这是受乔尔·斯波尔斯基的灵感启发的

这样的数据挖掘还可以让您识别代码维护时的集群，并将其与跟踪系统中的bug完成情况进行比较（除非您已经拥有了这两个记录之间的紧密集成和精确记录）

适当的ROI需要计算完全回报，因此需要考虑的是： -维护成本降低（明显） -停机或错过不能及时添加到发布中的新功能给业务带来的机会成本 -通过重构生成新产品线的能力

---

记住，一旦你有了一个导出数据的规则，你就可以对如何精确地计算东西进行争论，但至少你有一些数字来引导讨论

作为一个主要是单独或小型团队开发人员，这不属于我的领域，但对我来说，一个很好的解决方案是非常非常详细的计时，例如，使用一个方便的任务栏工具，当你去厕所时，它甚至可以过滤掉，并且可以将所有内容导出为XML

一开始可能会很麻烦，向团队介绍可能会很困难，但如果您的团队由于软件中的bug、错误或误解而每花15分钟就可以记录一次日志，那么您就可以积累令人印象深刻的、真实的数据，了解每个月技术债务的实际工资成本

我最喜欢链接的工具，因为它非常简单（甚至不需要数据库），并通过任务栏图标提供对每个项目/项目的访问。此外，还可以在那里输入有关所执行工作的其他信息，并且计时功能实际上是以秒为单位启动的。（我与供应商无关。）

有一个很好的插件（）来分析源代码，寻找这样一个指标。虽然您可能无法在构建中特别使用它，因为它是一个maven工具，但它应该提供一些良好的指标

下面是他们算法的一个片段：

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


 Where :

 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)

---

估计过去花费的金额可能更容易。一旦你做到了这一点，你应该能够提出一个估计未来的范围和逻辑，甚至你的老板可以理解

---

话虽如此，我对这类事情没有太多经验，只是因为我从未见过一位经理愿意在修复代码方面走这么远。当我们不得不修改糟糕的代码时，这一直是我们要解决的问题，因此重构实际上是所有修改和错误修复的隐藏成本。

+1了解杜邦对失去的商业机会的关注

我建议考虑一下管理层认为的这些机会。他们认为哪些因素会影响收入增长——新功能、上市时间、产品质量？将债务偿还与这些驱动因素联系起来将有助于管理层了解收益

关注管理层的看法将有助于避免错误计算。投资回报率是一种估计，它并不比其估计中的假设更好。管理层只会怀疑定量的论点，因为他们知道其中有一些定性的东西。例如，在短期内，你偿还债务的真正成本是程序员没有做的其他工作，而不是那些程序员的现金成本，因为我怀疑你是否会为此雇用和培训新员工。在未来开发时间或质量上的改进是否比这些程序员增加的特性更重要

此外，确保您了解产品的管理范围。如果管理层不考虑两年后，他们就不会关心18个月内不会出现的好处

最后，反思一下管理层的看法