我目前正在处理一个相当老的产品，这个产品由于过去糟糕的程序员和开发实践而产生了很多技术债务。我们开始变得更好了，技术债务的产生已经明显减缓。
我已经确定了应用程序中那些状况不佳的领域，并可以估计修复这些领域的成本，但是我很难估计投资回报率（ROI）。
代码将更易于维护，并且将来将更容易扩展，但我该如何为此付出一个美元数字呢？
一个好的起点似乎是重新进入我们的错误追踪系统，根据与这些“坏”区域相关的错误和功能估算成本。但这似乎很耗时间，并且可能不是最好的价值预测。
有人过去执行过这样的分析吗？对我有什么建议？
我认为你正在正确的方向上。
我没有计算过这个问题，但我曾与一位管理大型软件开发组织和大量遗留代码的朋友进行过几次讨论。
我们讨论的其中之一是通过分析版本控制系统提交来生成一些粗略的工作量指标，并将它们用于估计程序员工作小时数。这受到了 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个月后才会出现的好处。
最后，反思一下管理层的看法是如何让这个产品处于这种状态的。有什么变化会让公司更加关注技术债务吗？如果不同之处在于你——你比前任更好的经理——请记住，你的管理团队并不习惯考虑这些事情。你必须找到他们对此的兴趣，并专注于那些能够带来他们关心的结果的项目。如果你这样做，你将获得信誉，可以用来让他们考虑进一步的变化。但是，对收益的认识可能需要一段时间才能增长。作为一个大多数时间都是独自或小团队开发者，这个对我来说有些陌生，但对我来说，找出时间浪费的好方法是非常详细的时间记录，例如使用方便的任务栏工具this one，甚至可以过滤你去洗手间的时间，并可以将所有内容导出到XML。
起初可能会很麻烦，并且向团队介绍也是一个挑战，但如果您的团队可以记录每15分钟由于软件中的错误、错误或误解而花费的时间，您就可以积累令人印象深刻的现实数据，了解技术债务实际上每月成本是多少。
我链接的工具是我最喜欢的，因为它非常简单（甚至不需要数据库），并通过任务栏图标提供对每个项目/项的访问。此外，可以在那里输入有关所进行的工作的其他信息，并且时间记录可以在几秒钟内激活。（我与供应商没有任何关联。）
估算过去的成本可能更容易。一旦你完成了这个任务，你应该能够用范围和逻辑来估算未来的成本，甚至让你的老板们也能理解。
话虽如此，我对这种事情并没有太多经验，因为我从来没有见过一个经理愿意在修复代码方面走得这么远。通常我们只是在修改糟糕的代码时进行修复，所以重构实际上是所有修改和错误修复的隐藏成本。