我目前正在使用一个相当旧的产品，该产品背负着过去糟糕的程序员和糟糕的开发实践带来的大量技术债务。我们开始变得更好，技术债务的产生已经大大放缓。
我已经确定了应用程序中状况不佳的区域，并且我可以估算修复这些区域的成本，但我很难估算投资回报 (ROI)。
代码将更容易维护，并且将来更容易扩展，但我怎样才能在这些上放一个美元数字呢？
一个好的开始看起来像是回到我们的错误跟踪系统并根据与这些“坏”区域相关的错误和功能估算成本。但这似乎很耗时，并且可能不是价值的最佳预测指标。
过去有没有人做过这样的分析并对我有什么建议？
管理人员关心通过增长（首先是例如吸引新客户的新功能）和（其次）通过优化流程生命周期来赚钱。
看看你的问题，你的建议属于第二类：这无疑会落后于目标＃1（因此即使这可以省钱，也会被优先考虑......因为省钱意味着花钱（至少大部分时间;- ））。
现在，将美元数字放在“坏技术债务”上可能会变成更积极的旋转（假设以下情况适用于您的情况）：“如果我们投资于重新设计组件 X，我们可以更快地引入功能 Y，因此获得 Z 更多客户”。
换句话说，评估技术债务成本与失去商业机会的成本。
我认为你在正确的轨道上。
我不必计算这一点，但我与一位管理大型软件开发组织的朋友进行了几次讨论，该组织拥有大量遗留代码。
我们讨论过的一件事是通过分析 VCS 提交生成一些粗略的工作量指标，并使用它们来划分程序员工作时间的粗略估计。这是受到 Joel Spolsky 的Evidence-based Scheduling的启发。
进行此类数据挖掘还可以让您识别代码维护时间的集群，并将其与跟踪系统中的错误完成情况进行比较（除非您已经幸运地拥有两者之间的紧密集成和准确的记录）。
适当的投资回报率需要计算全部回报，因此需要考虑的一些事项是： - 降低维护成本（显然） - 停机业务的机会成本或错过无法及时添加以发布的新功能 - 能够由于重构而产生新的产品线
请记住，一旦您制定了导出数据的规则，您就可以就如何计算事物进行争论，但至少您有一些数据可以引发讨论！
Sonar有一个很棒的插件（技术债务插件）来分析你的源代码来寻找这样一个指标。虽然您可能无法专门将它用于您的构建，因为它是一个 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 表示 jldupont 专注于失去的商机。
我建议考虑管理层认为的这些机会。他们认为哪些因素会影响收入增长——新功能、上市时间、产品质量？将债务偿还与这些驱动因素联系起来将有助于管理层了解收益。
专注于管理认知将帮助您避免错误计数。投资回报率是一个估计值，它并不比在其估计中所做的假设好。管理层只会怀疑定量的论点，因为他们知道某处存在一些定性的论点。例如，在短期内，你偿还债务的实际成本是程序员没有做的其他工作，而不是那些程序员的现金成本，因为我怀疑你是否会为此雇用和培训新员工. 未来开发时间或质量的改进是否比这些程序员本来要添加的功能更重要？
此外，请确保您了解管理产品的范围。如果管理层不考虑两年后的情况，他们就不会关心 18 个月内不会出现的福利。
最后，反思一下管理观念让这个产品首先达到这个状态的事实。哪些变化会使公司更加关注技术债务？如果不同的是你——你是一个比你的前任更好的经理——请记住，你的管理团队不习惯考虑这些事情。你必须找到他们的胃口，并专注于那些能带来他们关心的结果的项目。如果你这样做，你将获得可信度，你可以用它来让他们考虑进一步的改变。但对收益的升值可能需要一段时间才能增长。
作为一个主要是孤独的或小团队的开发人员，这超出了我的领域，但对我来说，找出时间浪费在哪里的一个很好的解决方案是非常非常详细的计时，例如使用像这样的一个方便的任务栏工具，它可以甚至在你去厕所时过滤掉，并且可以将所有内容导出为 XML。
一开始可能很麻烦，并且向团队介绍是一项挑战，但如果您的团队可以每十五分钟记录一次由于软件中的错误、错误或误解而花费的时间，那么您就积累了令人印象深刻的真实数据基础关于每月实际支付的技术债务成本。
我链接的工具是我最喜欢的，因为它非常简单（甚至不需要数据库）并且通过任务栏图标提供对每个项目/项目的访问。还可以在此处输入有关所执行工作的其他信息，并且计时实际上是在几秒钟内激活的。（我不隶属于供应商。）
估计过去花费的金额可能更容易。完成此操作后，您应该能够对未来的范围和逻辑进行估计，即使您的老板也能理解。
话虽如此，我在这类事情上没有太多经验，只是因为我还没有见过愿意在修复代码方面走这么远的经理。当我们不得不修改不良代码时，我们总是会修复它，因此重构实际上是所有修改和错误修复的隐藏成本。