计算错误代码的成本

我正在寻找能说服管理层投入精力进行重构的论点。

我们使用Jira记录工作，并将每个svn-commit与jira调用相关联。

我的想法是执行以下操作：

• 手动发现极难实现但经常使用的代码区域：来自User-POV和Developer-POV的区域（错误修复）
• 获得包含JIRA问题的svn-commits
• 根据某些条件（问题类型，版本，优先级等）过滤问题
• 计算在这些错误上花费的时间/精力
• 估计工作量和重构风险
• 出示这些数字并寻求解决方法。

你觉得这怎么样？这样的测量是否有用和/或令人信服？优缺点都有什么？

我发现，如果您可以提供有效的数字，则经理更有可能采取行动。（如果他们能理解逻辑和成本/收益。）

恕我直言，要提出令人信服的案例，您需要执行以下操作以显示其严重程度：

• 针对该问题记录的支持事件数
• 花费时间维护/帮助不良代码/进行支持修复
• 基于进行维护/创可贴/支持的人员每小时的时间成本
• 展示这些项目对企业至关重要的某种方式

为了进行重构，您需要：

• 重构和实现这些不良事件的前三项的时间估计
• 实施的成本估算（与上述相同的每小时费率）

有了这些，您可以节省时间，前提是重构所需的时间大大少于前三项中每项3事件的支持时间。您可以争辩说，花费的时间越短，

• 少于n个支持事件
• 这些事情不会再发生这些事件了（甚至更好！）

但是，这笔交易中最难的部分将是回答以下问题，因为许多人没有按计划在预算中安排所有支持时间：

当您花时间处理X的这些问题时，我必须等待多长时间才能完成当前项目Y？ （尽管当前有支持时间，但无法在甘特图中预测和安排）

这在很大程度上取决于您与决策者的沟通水平以及他们如何了解情况。

我绝对认为这是值得做的，因此您可以练习使用指标构建案例，并节省自己的时间，即使他们不这样做也是如此。不幸的是，尽管有数据，但并不是每个人都容易说服。祝好运！

请记住，重构也引入了错误（您将在测试中捕获到错误，但是仍然是错误，必须将其修复）。不要意外拉动Netscape。这取决于您对“重构”的个人定义。对某些人来说，这意味着“将所有代码重写”为其他人，这意味着“更改某些内部”。你怎么知道你是什么样的人？问问自己以下问题：

我是否要完全更改公共界面？

如果答案是肯定的，那么您正在重新设计。如果答案是否定的，那么您正在进行重构，并且可能只是在日常活动过程中进行重构而无需特别批准。这与您的问题有关，因为重新设计会产生更多的错误，而重构通常更容易执行（因为您的测试已经具有公共接口，并且本身不需要进行修改）。

这是一个很难的案例，因为没人知道使用或不使用一年前进行的重构会花费多少X。以我的经验，务实的经理总是把这种事情付诸东流，因为：

1. 这种努力没有直接的收入来源（财务成本，不收费）
2. 丑陋的工作代码仍在工作，您冒着创造问题而不是解决问题的风险（潜在的质量成本）
3. 重构时其他项目将被延迟（时间成本）

所有这些数字最终都是基于猜测的，在您的情况下，您将不重构所需的成本与重构所需的成本进行了比较。您能做的最好的事情就是证明您具有某种数字上的事实依据，而且您的猜测相当不错。

优点是可以说服他们进行重构，这可能会有效，并且效果很好，可以减少错误的数量。

缺点是，如果花在修复错误上的时间减少的时间至少不及重构所花费的时间，那么您可能将不再被允许进行重构，而您可能会因为“浪费”的时间而受到指责。 。

通过降低整个项目的复杂性或使其更易于添加功能而节省的调试时间，可能很难衡量以至于无法为您提供太大帮助，但是您可以提到这些功能的存在。