重构时间与开发时间的最佳比例是多少？答案

【问题标题】：What is a good ratio of refactoring time versus development time?重构时间与开发时间的最佳比例是多少？
【发布时间】：2009-09-16 15:33:21
【问题描述】：

我正在尝试制定一个计划，让我们可以花更多时间进行重构。所以我想与行业标准进行比较，但我很难找到相关的研究或指标。

我觉得 20% 的开发时间花在重构上似乎是一个不错的比例，但我没有什么可证明的。

在我看来，对于 100% 或开发时间：

50% 用于编写代码、调试等...
30% 用于编写单元测试
20% 用于重构代码

因此，大约 1 行代码 2 书面最终出现在交付的产品中。显然，设计时间、文档时间等都包含在这些百分比中。

什么是行业标准？根据经验，您的团队正在使用什么？谢谢，奥利维尔

【问题讨论】：

非常感谢您的反馈！给出一些上下文。在过去的几年里，我们正在开发一种每年都会发布的产品。代码库是几百万行代码，有 30 多个 SE 在上面工作。代码质量随着时间的推移而下降，积累了技术债务。由于各种原因，很难改变文化并定期使用单元测试和重构。我们刚刚从每年的瀑布转换为每月的冲刺。为了说服管理层，我想对我们应该花费多少时间（可能由外部团队）进行衡量。谢谢，奥利维尔
不断增加的技术债务最终会扼杀你的速度，这就是我试图向管理层解释的原因。也许这可以帮助：infoq.com/news/2006/11/ken-schwaber-code-quality

标签： unit-testing refactoring time

【解决方案1】：

您的评论说您有数百万行代码但没有单元测试，而且您很难让管理层相信单元测试是值得的。根据 Fowler 的书，重构需要伴随着单元测试，以确保您在重构时不会破坏任何东西。我同意，并且我建议在这个阶段单元测试将比其他任何东西提供更多的价值，所以首先要实现这个目标。我强烈推荐 Michael Feathers 的书“有效地使用旧代码”，以获取有关如何执行此操作的建议。您甚至不必编写更多的单元测试来使其成为一项值得付出的努力，只需让框架运行即可。

第 0 步：在您的代码中使用自动化单元测试框架。

你不会试图独自完成这件事，是吗？这是一个大项目，我希望你是一个与你分担痛苦的高级技术团队的一员。你需要让他们所有人都接受这 100%。当你去找你的老板时，你需要他们的支持，你需要他们的专业知识来分享你的设计，你需要他们对设计的完全同意。

第 1 步：召集一队。

没有计划和目标，重构不会有太大帮助。您是否希望只是将代码切碎并使模块更小？您是否要将代码组织到域中？您是否要尝试将一些服务接口插入其中？您要重构为 n 层架构吗？你和团队认为需要做什么？您将如何将此设计和重构计划传达给 SE？

第 2 步：让团队进行一些初始架构设计和最终状态规划。

现在是最难的部分。您要求 30 名工程师的 20% 的时间，每年可能超过 500,000 美元。您将需要比“累积的技术债务”更多的理由。您需要展示投资回报率。

所以准备好回答你的老板肯定会问的问题：“我为什么要这样做？”您期望通过重构获得什么？您是否会将新功能的开发工作量减少 10%？ 100%？你会提高代码质量/减少错误/降低支持成本吗？您会加快产品上市时间吗？多少？这会让您减少 SE 或承包商人数吗？多少？或者您能否在每个版本中添加更多功能？也有负面影响：如果给你一年的时间进行重构，会有多少功能会被延迟？他们会延迟多久？

第 3 步：进行一些认真的估算。

因此，既然您已经掌握了设计、计划、金钱上的理由，并且得到了技术人员的支持，那么请回到您的老板那里，向他或她展示您的案例。你会比说“我们应该花 20% 的时间重构，互联网上的一些人这样说”要好得多。

【讨论】：

这就是我的计划。我想知道一个好的经验法则，这样我就可以与我们正在做的事情进行比较，并将其用作另一个支持指标。毕竟，很难得出确切的 ROI 数字，因为它只是在一天结束时进行的估计。无论如何，我在这里看到的数字在 5% 到 30% 之间变化，具体取决于当前状态。我想这一切让我确信没有行业标准，所以我要从我的演讲中删除这个神奇的数字:)。
嗯，这正是我所做的。我们现在有一个不完全是我想要的项目（当然，这是委员会的妥协），但它已正式发布，现在正处于设计阶段。即使它并不完美，但管理层承认我们的产品仍然值得投资。

【解决方案2】：

我怀疑有任何规范。

让您崩溃：大多数团队不编写单元测试也不重构（直到某些东西中断或停止开发）。最常见的重构时间分配是

如果你对好的做法感兴趣，那么......

重构可能是作为开发过程的一部分的持续活动。您看到了改进的潜力，并且您个人分配了一些小时间来使事情变得更好。这里重构时间
您执行定期代码审查。说，几个月一次。然后你可以专门为团队专门花几天时间来审查他们的代码并改进它。这里也有

【讨论】：

有任何论文/研究/统计数据来支持这些说法吗？
以上数字代表我的看法和常识。

【解决方案3】：

我并没有真正为重构、单元测试和文档等事情指定单独的时间。我只是将它们视为成品的一部分，直到它们完成才完成。

【讨论】：

很高兴听到有人知道他们在说什么。

【解决方案4】：

第一点，编写代码/调试/重构是 IMO 一项独特的活动，应该在项目的整个生命周期中进行。完美的设计并不真正存在，因为设计是短暂的。今天完美的东西可能会因明天的新要求而完全失效。

第二点，我见过许多项目，其中编写单元测试比编写代码使它们通过需要更多时间。

所以对我来说，比率更像是：

50%：单元测试
其余的：编码/调试/重构/文档

【讨论】：

【解决方案5】：

您的设计方法是什么？瀑布？敏捷？你的项目有多大？你的团队有多大？

我在进行敏捷开发时效率最高的往往是 33/33/33，甚至可能是 30/30/40。一旦你编写了测试，然后编写了代码以通过测试，你就可以重构和磨练代码，确信你没有破坏任何东西。

在一个小型项目中，您可以假设完美地构建您的代码，而无需测试/重构（我从未见过这真的有效）。在一个大型项目中，或者在一个有很多人参与的项目中，或者在一个有很多客户要求很多不同东西的项目中，重构和测试远比代码本身重要。

这就像问，在房子的整个生命周期中，你应该建造多少次房子，你应该查阅多少次建筑规范，以及你应该进行多少次维护。显然，建造房子是最重要的事情，理论上，你可以建造一座不需要装修的“完美”房子，但这不太可能。

您更有可能花费一两年时间来建造房屋，而房屋的其余部分则需要定期翻修。加强承重构件比建造甲板更重要，即使您的客户要求甲板。他们会不高兴，但如果屋顶塌了，他们会更不高兴，而他们只能住在甲板上。

同样，您会花费 X 时间编写代码，但更多的时间会在项目的生命周期中进行重构和优化。

【讨论】：

【解决方案6】：

如果您难以理解您的代码，那么是时候重构了。

否则，您可能会因为对代码功能的误解而浪费时间进行调试；换句话说，你已经承担了太多的债务来冒险不进行重构。

同样，如果您不确定一段代码的作用，请务必编写一个单元测试来验证您的理解。

这些只是我遵循的经验法则，这样我就不会在调试器中浪费太多时间。因此，我花在重构上的实际时间实际上变化很大，具体取决于代码的复杂性和我所处的开发阶段。此外，如果代码过于复杂，这通常表明必须将类分解成更小、更易于理解和更易于维护的部分。

【讨论】：

这应该是公认的答案。一句话，kfmfe04 抓住了我们重构的全部原因。

【解决方案7】：

这取决于许多因素，例如您所在的业务类型、公司使用的流程类型、您所在的团队类型、您使用的语言等。

他们绝对没有正确的答案。如果您所在的领域的需求变化很大，并且如果客户变化很大并且您使用敏捷方法，那么您将更容易受到重构的影响。如果您在一家银行，并且您的团队使用级联方法，那么您更倾向于编写代码进行更多和更少的重构。

【讨论】：

【解决方案8】：

我认为这样的比率会因人员、项目、工具以及可能的其他因素而有很大差异。然而，通常，这将在调试和/或测试中考虑，因为在一个新项目中，它通常是处理稍后发现的问题的一部分。在最初的代码编写中也会发生一些事情。

【讨论】：

【解决方案9】：

我的重构方法是在修复问题的同时进行。 重构的好处只有在维护代码时才会出现，因此重构没有很多错误且不需要任何新功能的代码几乎没有什么好处。

每当我修复错误时，我都会寻找重构的方法，即重构时间包含在编写代码/调试类别中（我认为这是两个独立的类别）。

【讨论】：

【解决方案10】：

对于好的、设计良好的代码，我认为 5% 或更少的代码适合持续开发。

对于需要认真重新设计的有问题的代码，在添加新功能或修复严重错误之前，您可能需要为前期重构预算更高的百分比。

【讨论】：