我正在努力制定一个关于如何花更多时间重构的计划。所以我想与行业标准进行比较，但我很难找到相关的研究或指标。
我觉得花费在重构上的开发时间的20％似乎是一个很好的比例，但我没有任何东西可以显示它。
在我看来，100％或开发时间：
因此，大约有1行代码，最终会出现在已发货的产品中。 显然，设计时间，文档时间等都集成在这些百分比中。
什么是行业标准？根据经验，您的团队使用什么？ 谢谢， 奥利弗
答案 0 :(得分：3)
您的评论说您有数百万行代码但没有单元测试，并且您很难说服管理层单元测试是值得的。根据福勒的书，重构需要伴随单元测试，以确保您在重构时不会破坏任何东西。我同意，我建议单元测试在这个阶段提供比其他任何东西更多的价值，所以首先要达到这个目标。我强烈推荐Michael Feathers的书“有效地使用遗留代码”，以获取有关如何执行此操作的建议。您甚至不必编写多个单元测试来使其值得付出努力，只需让框架运行即可。
第0步：获得一个自动化的单元测试框架，用于您的代码。
你不会单独尝试完成这个，是吗？这是一个很大的项目，我希望你是一个与你分享痛苦的高级技术团队的一员。你需要让他们全部购买这100％。当你去找老板时，你需要他们的支持，你需要他们的专业知识来分享创作设计，你需要他们完全同意设计。
第1步：聚集一个团队。
没有计划和目标，重构不会有太大帮助。你是希望只是将代码砍掉并使模块更小？您是否要将代码组织到域中？你打算尝试将一些服务接口加入其中吗？你打算重构一个n层架构吗？你和团队认为需要做什么？你如何将这种设计和重构计划传达给社会企业？
第2步：让团队做一些初步的建筑设计和规划最终状态。
现在是困难的部分。你要求30个工程师20％的时间，这可能超过每年500,000美元。与“累积的技术债务”相比，你需要更多的理由。你需要显示投资回报率。
所以准备好回答老板肯定会问的问题：“我为什么要这样做？”您希望通过重构获得什么？您是否会将新功能的开发工作量减少10％？ 100％？您是否会提高代码质量/减少错误/降低支持成本？你会加快产品上市时间吗？多少钱？这会让你减少SE或承包商的人数吗？多少？或者您是否可以在每个版本中添加更多功能？还有一些消极因素：如果给你一年的重构，有多少功能会延迟？他们将延迟多久？
第3步：做一些认真的估算。
所以现在你已经拥有了设计，计划，货币理由，并且得到了技术人员的支持，请回到你的老板那里，向他们展示你的案子。你会比说“我们应该花20％的时间进行重构，比互联网上的一些人说的那样好运。”
答案 1 :(得分：2)
我怀疑是否有任何规范。
对于您的故障：大多数团队不编写单元测试而不进行重构（直到出现故障或停止开发）。最常见的是，重构时间分配是＆lt; 1％。
如果你对良好实践感兴趣那么....
作为开发过程的一部分，重构可能是一项持续的活动。你看到了改进的潜力，你个人分配了一些时间来让事情变得更好。这里的重构时间＆lt; 5％。
您执行常规代码审核。比如，几个月一次。然后，您可以专门为团队专门花几天时间来审核他们的代码并进行改进。这里也＆lt; 5％。
答案 2 :(得分：2)
第一点，编写代码/调试/重构是IMO一个独特的活动，应该在整个项目的整个生命周期中发生。完美的设计并不存在，因为设计是短暂的。今天完美无缺的事情可能会被明天的新要求完全无效。
第二点，我看过许多项目，编写单元测试比编写代码需要更多时间才能使它们通过。
所以对我而言，比率更像是：
50％：单元测试
答案 3 :(得分：1)
我的重构方法是在解决问题的同时进行。 重构的好处只有在维护代码时才会出现，因此重构没有很多错误并且不需要任何新功能的代码几乎没有什么好处。
每当我修复一个bug时，我都会寻找重构的方法，即重构时间包含在编写代码/调试类中（我认为这是两个不同的类别）。
答案 4 :(得分：1)
我并没有为重构，单元测试和文档等事项指定单独的时间。我只是认为它们是成品的一部分，直到工作才完成。
答案 5 :(得分：1)
您的设计方法是什么？瀑布？敏捷？你的项目有多大？你的团队有多大？
我在进行敏捷开发时所做的最富有成效的趋势是33/33/33，甚至可能是30/30/40。一旦你编写了测试，然后编写代码来通过测试，那么你就可以重构和磨练代码，相信你没有破坏任何东西。
在一个小项目中，您可以假设地完美地构建您的代码，而不必测试/重构（我从未见过这实际上有效）。在一个大型项目中，或者有很多人参与其中的项目，或者有许多客户要求许多不同事物的项目，重构和测试远比代码本身重要。
这就像在房子的整个生命周期中一样，要求你多次建造房屋，要多少次咨询建筑规范，以及应该多少次进行维护。显然，建造房屋是最重要的，理论上，你可以建造一个“完美”的房子，不需要在线下进行翻新，但这不太可能。
你可能会花一两年时间建房子，房子的其余部分会定期翻新。即使您的客户要求使用甲板，加固承重构件也比构建甲板更重要。他们会不高兴，但如果屋顶落入他们所有他们必须居住的是甲板，他们会更加不高兴。
同样，你花费了大量时间编写代码，但是在项目的整个生命周期中重构和优化它的时间更多。
答案 6 :(得分：0)
这取决于许多因素，例如您所处的业务类型，公司使用的流程类型，您所在的团队类型，您使用的语言等。
他们绝对没有正确答案。如果你在一个需要大量移动的领域，并且如果客户端发生了很大变化并且你使用了敏捷方法，那么你将更容易进行重构。如果你在一家银行，并且你有一个使用级联方法的团队，你就更容易编写代码，而不是重构。
答案 7 :(得分：0)
我认为这样的比例会因人，项目，工具和其他可能的东西而有很大差异。但是，通常情况下，这将在调试和/或测试中得到解决，因为在新项目中，它通常是处理稍后发现的问题的一部分。在最初的代码编写中也会有一些进展。
答案 8 :(得分：0)
对于好的，精心设计的代码，5％或更少的声音对我来说是正确的持续发展。
对于需要严格重新设计的有问题的代码，在添加新功能或修复严重错误之前，您可能需要为预先重构预算更高的百分比。
答案 9 :(得分：0)
如果您很难理解代码，那么就该重构了。
否则，由于对代码的误解，您可能会浪费时间进行调试;换句话说，你承担了过多的债务风险而不是重构。
同样，如果您不确定代码的作用，请确保编写单元测试以验证您的理解。
这些只是我遵循的经验法则，因此我不会在调试器中浪费太多时间。因此，我花在重构上的实际时间实际上取决于代码的复杂程度以及我正在开发的阶段。此外，如果代码过于复杂，那通常表明类必须分解为更小，更易于理解和更易于维护的部分。