如何衡量重构的潜在价值

在具有技术债务的旧的大型项目中，如何可靠地估算或衡量重构代码的收益？

例如，假设您在软件堆栈解决方案中有一些组件是用较旧的语言编写的，而某些较后的组件是用较新的语言编写的。开发团队将不断向该解决方案添加新功能和错误修复。

开发人员建议用新版本替换现有的旧语言组件将是“一件好事”。但是，这项工作不会增加任何额外的功能，这将花费x开发日。

销售人员建议添加“一项很棒的新功能”。公司通过使用公式来衡量他的建议的价值。即。它将在t年内以x开发日的工作成本为公司赚取F百万英镑。

公司如何以有意义的方式增加重构建议的成本？在什么情况下，这可能是公司最赚钱的选择？

它将在t年内以x开发日的工作成本为公司赚取F百万英镑。

它忽略了维护成本，支持成本，销售/市场营销成本，并且对如何在市场中使用该功能做出了大量假设。

但是无所谓; 您所要查找的问题很清楚：

我该如何提出重构业务案例？

要实现的主要目标是时间等于金钱。您可以直接进入“ 5个开发人员2周= 80小时* 5个开发人员* $ 50 / hr-> $ 20,000”，这对商务人士来说很有意义。精明的商人会注意到，向这5个开发人员的付款方式都是相反的，您可以反驳这不是在花费/节省20,000美元，而是在以最有利可图的方式使用20,000美元。无论如何，在列表上。

• 效率 -大概来说，用C＃比VB6可以完成更多的工作。更好的工具，更好的库等。新技术往往比旧技术更好。如果您可以在更短的时间内完成工作，那意味着您可以节省公司的钱。
• 开销 -编码不是唯一的软件成本。考虑一下Windows 2020出现时会发生什么。您将花费多少时间和精力来使该VB6应用程序运行起来？这比C＃应用程序花费更多的时间和精力？那为您省钱。
• 质量 -大概来说，用C＃可以完成比VB6更高质量的工作（或者使用更简洁的体系结构，或者您的重构目标是其他任何东西）。更高的质量意味着更少的错误。更少的错误意味着更少的错误修复成本，更少的客户支持成本以解决这些问题，更少的客户因质量问题而损失，因质量声誉而增加的销售...对您的公司来说都是一笔不小的钱。
• 人力资源储蓄 -让我们面对现实：没有人愿意使用该糟糕的VB6应用程序。这意味着更多的人将离开公司，从而花费时间和金钱来更换他们。这意味着雇用新员工需要更多的时间和金钱。最糟糕的是，这意味着您将拥有使用该VB6应用程序完全可以自杀的开发人员。这些开发者反过来又加速了质量问题的死亡螺旋。减少营业额和雇用时间可以节省公司资金。放任自满，cr脚的开发人员可以节省您的公司。
• 士气 -同样，已经在那里的程序员也讨厌在VB6中工作。他们会做到的，甚至可能会做得很好。但是很烂。也许不适合所有人，但肯定适合某些人。这意味着要花更多的时间浏览网络以恢复动力。这意味着更长的午餐。这意味着更少的工作要做，而程序员则需要更长的时间才能从繁琐的工作中恢复。
• 功能 -这不适用于技术驱动的重构，但适用于体系结构重构。某些代码问题会导致您无法提供出色的功能X来赚钱。也许您无法扩展。也许您无法获取数据来进行出色的信息学研究。也许代码是如此棘手，以至于很难真正完成这项工作。随你。有时您就在那个时候，有时您正朝着那个点开车。很难翻译成商务用语，但如果可以的话，“这个问题使我们无法利用X，Y和Z的机会”可能会很强大。

总而言之，归结为“这些东西将帮助我们更好地完成工作；如果我们更好地完成工作，我们可以为您节省/赚更多的钱”。

您应该问自己的问题是，销售人员如何知道该功能将花费x开发人员工作日的时间。鉴于即使是具有多年专业经验的优秀项目经理也常常无法分辨这一点，因此，来自销售人员的此类数据似乎极具推测性。

根据我的经验，销售人员通常不进行估算，但会猜测对管理人员或客户而言太多了：如果管理人员准备支付50个工时周的工作，但绝对会拒绝75个工时周的工作，那就告诉我们该功能将需要花费70个工作周来准备重新协商（实际估计这是毫无疑问的），最多需要55个工作周。

• 一方面，您有由IT专家完成的估算，这些估算表明：

  根据这项特定的审核，与使用新技术的类似规模的类似项目相比，我们每天使用过时的技术浪费了8000美元。迁移整个代码库似乎还需要50到80个工作日。在此期间，不会发布任何新功能。迁移特定组件也有10％的风险，这可能导致20-30个额外的人工周工作。

• 另一方面，推销员在与需要说服的人进行谈判时会根据他们的影响力做出猜测。

这完全取决于您在公司中的影响力。沟通是这里的关键，这是销售人员通常在向管理人员（或客户）解释功能优势时赢得IT专业人员的机会。

请注意，如果您过去的估算非常准确，您将获得声誉和影响力。如果您的估计总是错误的，那么管理层可能会忽略您的建议。

至于估算，由于要考虑很多参数，因此在这里做出有价值的估算非常困难。除其他外：

• 您实际上知道与VB6相比，您的C＃团队熟练吗？是基于实际测量还是只是猜测？

• 这个团队是否使用C＃开发了大型项目？他们是否知道应该使用的工具（IDE，调试器，分析器等）？您是否需要其他许可证（在Microsoft的世界中，这意味着每台计算机数千美元）？

• 当前项目是否完全清晰，您可以保证迁移时不会有意外？重写所有内容，每个功能是否简单明了，还是会有惊喜？

• 您有支持C＃的基础结构吗？持续集成又如何呢？那你的构建服务器呢？风格指南？静态检查器？

• 在生产中，服务器（如果是Web应用程序）或客户PC（如果是台式机应用程序）是否能够运行您希望使用的.NET Framework版本？

但是最重​​要的是要知道为什么要重写所有内容。什么是你试图通过重写来解决这个问题？生产力下降？您如何衡量？您如何向管理人员显示这种生产力损失？

一旦证明自己由于VB6浪费了每天$ 8 000（这意味着一旦迁移到C＃，您每天将节省$ 8 000），如何解释进行每个新功能开发的好处以及专注于完整的重写？与渐进式重写相比，您在交付新功能时一小块一小块地迁移组件有什么好处？

首先，您需要像销售驱动功能请求那样估算重构的开发成本。

如果这是一项繁重的工作，要获得准确的结果可能很棘手，但是，假设您在2种技术方面有足够的经验，那应该是可行的。

其次，您需要估算不重构的成本。如果您正在为我做估算，我希望能有一定程度的指标。例如，四分之一以上的VB代码和C＃代码的平均开发成本之间的差异。或一些这样的。显然，这取决于您对此进行跟踪的准确性。

使用这两个数字，您可以估计重构将给您的投资回收期，即重构将在什么时候从净成本变为净收益。

我只能猜测任何给定结果的说服力。但是，如果不到一年，它可能会非常强大，超过2年，那么您可能会很挣扎。

另外，可能值得添加其他维度来帮助您构建案例。我过去使用过的一种方法是查看是否有出口采访将这项技术作为推动因素。如果是这样，您可以辩称重构将保留人员（招聘和培训非常昂贵）。

显然，您可以在没有证据支持的情况下争论这些事情，但是我发现这可以对案件的影响产生巨大影响。

重构的价值来自多种不同的方面。

它可以帮助您以后进行其他更改，因此该功能原本需要花费X天的时间才能完成2 / 3X天。要使用敏捷术语，它可以提高速度。

随着时间的推移，列出的显式更改会有所帮助，因为您将不再需要维护具有VB6经验的开发人员，而只需维护具有C＃经验的开发人员。

它还以其他不切实的方式提供帮助，例如人员保留和招聘。做C＃和VB6的工作会比只做C＃的工作更具吸引力吗？您是否会或多或少地工作或留在一个不错的代码库或糟糕的代码库上工作？

我认为其他答案遗漏的一点是，您需要根据未重构带来的收入损失来衡量重构成本。

为了更改代码而进行重构是浪费时间。它需要为表带来价值。在这种情况下，我并不是要花费一个小时来重构问题类，而是要进行主要的重构，例如更改为示例中所用的另一种CLR语言。

• 如果我们继续做我们正在做的事情，我们会错过某些事情吗？是否有一个过时的旧设计阻碍了我们实现价值？例如，如果我们要添加一个功能，是否如此困难，以至于可能需要100个小时来实施，而重构需要50个小时，而重构需要25个小时？

• 现有法规是否承担着使我们付出金钱的技术债务？这个糟糕的旧代码是Bug的源头吗？我们是否最终会因此而免费解决问题？没有人喜欢免费提供可观的收费时间。

• 重构的成本等于或小于不重构的成本吗？

• 是否可以由一小撮摇滚明星来重构导致最多问题的代码来摊销成本？我们可以将重构分散到各个版本中吗？到处都是低效率的问题：我们可以“填补空白”吗？

重构系统的好处

通过比较执行和不执行之间的业务底线收益，可以为重构提供业务案例。这意味着要么减少当前的实际成本，要么增加未来的实际现金流入。

受重构影响的主要预算项目如下：

• 维护成本-如果当前系统是一堆易碎的意大利面条，并且在实践中可以观察到修复小错误（包括开发和运营中的小错误）需要大量的工时，则可以预期这样的成本对于“适当重新设计”的系统，维护费用将减少。看一下您的年度纯维护成本是多少，以及在重写后如何实际改变。

• 添加新功能的成本-同样，如果当前的系统设计和结构使编写新功能的时间浪费在不合理的时间上，那么重写可能会节省成本。查看新功能的计划预算，但要切合实际-如果您声称将看到50％的改进，那么您期望在x工时中实际开发功能，而先前需要2 * x工时才能实现。这样的承诺可能很难兑现。

• 软件质量对销售的影响-如果当前系统尽管进行了充分的维护，但经常导致客户可见的问题（例如崩溃或停机），那么重写可以作为解决方案。如果这是一个主要问题，那么相同的销售人员就可以量化称为“更稳定的产品”的“功能”的价值。

如果以上三点没有达到预期的重写成本（甚至更高）；则将x开发日花费在非功能上的机会成本等于这些功能的价值，这大于x开发的纯成本天），那么恐怕就是这样-预期的节省并不能证明重写的合理性。

另外，如果您的路线图没有显示“尽可能提供新功能”的需求，则节省的形式应该是“以前需要10个人完成所有必需的工作，但是在重写之后，我们“只用6个人就可以做同样的事情”。如果您可以“出售”比拥有开发人员的开发项目更多的开发项目，那么提高效率可以使您开发更多的东西，但是如果使用当前资源的企业已经能够开发所有带来额外价值的东西，那么唯一的财务收益可能来自更少的人薪水或更便宜的人。

重构的价值可以这样衡量：当前的新功能x将花费5个开发者2周。如果我们重构旧组件，则新功能的成本估计将减少20％。因此，新功能x在2周内仅花费4个开发人员。

重构是减少未来开发成本的一项投资。如果您不能在重构时使用该参数，则可能没有业务案例。