计算错误代码的成本

Question

我正在寻找论据来说服管理层将精力投入到重构中。

我们使用Jira记录工作，并将每个svn-提交到jira调用关联起来。

我的想法是做以下工作：

• 手动发现实现非常糟糕但经常使用的代码区域:来自User和Developer-POV (错误修复)。
• 获取包含JIRA问题的svn-提交
• 根据某些标准(问题类型、版本、prio )过滤问题。等等.
• 计算在这些bug上花费的时间/精力
• 估计重构的努力和风险
• 提出数字，并要求努力解决它。

你觉得这个怎么样？这种衡量方法是否有用和(或)令人信服？什么是Pros和Cons？

Answer 1

我发现，如果你能提供有效的数字，经理们更有可能采取行动。(如果他们能够理解逻辑和成本/效益。)

国际水文学组织，要有令人信服的理由，你需要以下几点来说明它有多糟糕：

• 为这些问题记录的支助事件数目
• 花在维护/带带上的时间-帮助错误的代码/做支持修复
• 基于维护/带辅助/支持人员每小时费率的时间成本
• 演示这些任务对业务的重要性的一些方法

为了支持重构，您需要：

• 对这些坏事情中的前3件进行重构和实现的时间估计
• 执行费用估计数(与上文所用小时费率相同)

有了这些，您就可以节省时间，如果重构所花费的时间比支持前3项中的每一项事件的时间都少得多。你可以说这么短的时间

• 少于n次支援事件
• 这样的事情不会再发生了(更好！)

然而，最困难的部分是回答以下问题，因为很多人没有为你所做的所有支持在计划中安排时间：

在您花时间处理X?时，我还要等多久才能完成目前的Y项目？(尽管目前的支持时间链接无法在甘特海图中预测和安排)

这在很大程度上取决于你与决策者沟通的好坏，以及他们对形势的理解。

我绝对认为这是值得一做的，所以您可以使用度量标准来构建案例，并节省您自己的时间，即使他们不支持。不幸的是，并不是每个人都很容易被说服，尽管有数据。祝好运!

Answer 2

请记住，重构也会引入bug(您将在测试中捕捉到这些bug，但仍然是bug，必须修复)。不要在事故中拉网景。这取决于你个人对“重构”的定义。对一些人来说，这意味着对另一些人“重写所有的代码”--这意味着“改变一些内部结构”。你怎么知道你是哪种人？问自己以下问题：

我在改变公共界面吗？

如果答案是肯定的，你正在重新设计。如果答案是否定的，那么您正在进行重构，并且可以在没有特殊批准的情况下在日常活动过程中进行重构。这与您的问题相关，因为重新设计会产生更多的bug，而重构通常更容易执行(因为您的测试已经使用了公共接口，并且不需要自己进行修改)。

这是一个很难做的例子，因为没有人知道一年前做的重构会花费多少钱。根据我的经验，务实的管理者总是把这类事情打倒，因为：

1. 没有直接的收入来源于努力(财务成本，而不是可收费的)
2. 丑陋的工作代码仍然是工作代码，您可能会产生问题而不是修复它们(潜在的质量成本)。
3. 当您重构时，其他项目将被延迟(时间成本)

Answer 3

所有这些数字最终都是基于猜测，在您的情况下，比较您猜测的不重构的成本与重构的成本。你能做的最好的就是向你展示你有某种数字的，事实的基础的猜测，你有一个相当好的一个。

优点是，它可能会有效地说服他们让你重构，这可能会很好，减少bug的数量。

缺点是，如果修复bug所花费的时间不像重构所花费的时间那样少，那么您很可能不再被允许进行重构，而且您可能会因为“浪费”的时间而受到指责。

通过降低整个项目的复杂性或使添加特性变得更容易而节省的调试时间可能很难度量，无法对您有很大帮助，但您可以提到它们是存在的。