团队通常很难说服产品负责人给他们时间做重构，特别是重构工作量较大的时侯。

什么是重构？

重构，是指在不改变代码外在行为的前提下，优化代码的结构。

这就意味着，团队不会将重构用于修复bug，因为修复bug需要改变代码的外在行为。然而，团队却可以通过重构来防止产生更多的bug。

实际上，防止将来出现问题是实施重构的最常见原因之一。

例如，团队遇到了产品某部分代码bug过多的问题，团队想要对该代码做个“清理”（重构），以便将来再访问该代码时，程序不会如此脆弱。

然后，你就能明白：在优化代码结构而非行为时，为何产品负责人会难以理解和优先安排重构工作。

评估不重构的成本

遵循以下这些步骤，将重构项以经济视角提交给产品负责人，产品负责人对是否投资重构就能更容易地作出决策。

步骤1：评估现状（不重构）会造成的影响

针对您想重构的代码，收集在此代码上进行缺陷分析、修改和验证所花费的时间。当拿不到实际数据时，可以进行有根据的猜测。

如果确实需要猜测，建议进行保守猜测，避免为了重构而夸大事实。这样团队能更加确信：他们是真地在推荐一个明智的选择，而非仅仅出于喜好。

否则，当他们因过度承诺技术工作（例如重构）的好处而出名，团队未来再兜售类似技术工作的好处时会变得很艰难。

一个案例

来看一个混合应用实际数据和团队凭经验猜测数据的案例（这种情况是最常见的）。

在本案例中，团队深挖了产品待办列表或缺陷跟踪软件，以确定系统中某特定功能域到底报告了多少个bug。他们决定查看前六个双周迭代的数据（约三个月）。在使用更多数据和花更多时间进行分析之间，三个月是一个很好的折衷方案。

通过查看前六个迭代中执行的工作，团队确定这段时间共修复了12个bug，其中8个被归类为“高”严重级别，4个为“中”严重级别，此外还有3个严重级别为“低”的缺陷没有被修复。

这就是所有的数据。

如果团队在过程中记录了修复这些bug的实际工作量，那么就使用它。然而，很多团队并不会记录这些数据，那就可能需要对缺陷修复花费的时间进行猜测。这是OK的，正如你将看到的，数据并不需要太完美。

我们不妨假设：团队估计修复每个“高”严重级别的bug需要花12个小时，其中包括了bug分析、编码、测试以及任何其它用于讨论或记录解决方案的时间。

接下来，团队猜测：每个“中”严重等级的bug花了一半时间，也就是 6个小时/个。

综合起来，我们的团队在过去三个月里共花了120（ 8*12 + 4*6 = 120）个小时来修复bug。

那怎么处理未修复的bug？

别忘了，还有三个“低”严重级别的bug被报告而又没有修复。处理这些bug，需要打个电话来判断。

如果产品负责人确实真心希望修复这些bug而又没能够做到，那么就要把修复它们的估计值也包括在内。反之，如果团队对“低”严重级别的定义是：这些缺陷微不足道和无需修复，那么就可以将其排除在计算之外。

为何建议采用小时而非故事点？

建议在计算中使用小时，因为大多数团队都不会以故事点来度量缺陷。但是，如果您的团队确实是使用故事点来估计缺陷的，那么不妨在计算中使用故事点。

步骤2：估算实施重构所需的工作量

要做到这一点，团队成员应该像估计任何其他产品待办项一样估计重构项。这就意味着，要以故事点或小时来进行估计。

然后，团队需要把此估计值的单位转化为与步骤1一致，即估计不重构会造成的影响时采用的单位。

我们不妨假设：团队有一个对某不良代码进行重构的产品待办项。建议开一个类似于小型迭代计划的会议，讨论重构预计会有哪些工作。

例如，他们可能会认为只需要进行编码和测试。但为更好地理解工作，他们将其拆分为3个编码任务和2个测试任务。每项任务都进行了快速而粗略的估计——再次重申“数据无需完美”。在我们的例子中，假设：总共为40个小时。

步骤3：估算重构完成后将会节省多少时间

这通常仍然会是实际数据和有根据猜测的结合。

为了搞清楚如何做到这一点，再次回到我们的案例。

在第一步中，团队查找了数据，确定在前六个迭代中他们修复了12个缺陷（8个“高”严重级别、4个“中”严重级别），他们估计共花了120个小时来修正这些缺陷。

这意味着团队平均每个迭代花了20小时（120÷6=20）来解决他们想重构代码中的缺陷。

在大多数情况下，认为重构能消除所有旧代码的缺陷和所有对旧代码的再次访问需求，是不现实的。因此，团队假设：他们提出的重构项，能使系统中该领域的缺陷投入时间减少一半。

换句话说，重构将能使每迭代处理系统中该部分缺陷需花费的时间，从20个小时/迭代减少到10个小时/迭代。

或许团队能改进得更多，但建议在估计改进成果时仍然持保守态度。

步骤4：估计投资回收期

是时候看看是否值得实施重构了。

要做到这一点，需将执行重构所需投入的工作量（在步骤2中确定）除以节省下来的时间（在步骤3中确定）。

在本案例中，团队估计重构需要花40个小时，并且他们估计每迭代可以节省10个小时。

投资回收期的计算方法是：将重构所需的小时数除以每迭代节省的小时数，如下所示。

由于团队为重构规划了40个小时，并且每迭代将会节省10个小时，所以投资回收期是4个迭代。

四个迭代的投资回收期，应该能获得大多数产品负责人的青睐。这意味着在四个迭代后，就能收回用于重构的时间，并且与重构前相比，团队后续每个迭代都将会有额外的时间可用。

投资回收期需要多短？

团队和产品负责人应该寻找投资回收期最短的重构机会，但不存在严格的“所有重构都必须在n个迭代中得到回报”的指导标准。

投资回收期多长才合理？这会受项目的诸多因素影响，包括其他特性的紧迫性和产品的预计寿命等。

难以证明：产品集的任何重构工作的有效期都会少于六个月。

以产品负责人的术语来提交论据

通过使用以上四个步骤来评估重构，团队能为重构展示其经济情况。他们对投资（执行重构所需的时间）除以每迭代节省时间的粗略估计，使产品负责人能大致了解多久能收回投资。

当以这些术语向产品负责人提出重构的论据时，产品负责人可以根据重构的经济效益做出合理的决策。

这对团队、产品负责人以及产品的用户和客户都有利。