问重构时间与开发时间的好比率是多少？

EN

您的评论说，您有数百万行代码，但没有单元测试，而且您很难说服管理层单元测试是值得的。根据福勒的书，重构需要伴随单元测试，以提供信心，你没有破坏任何东西，而你重构。我同意，并且我建议在这个阶段单元测试将提供比其他任何东西更多的价值，所以首先要实现这个目标。我强烈推荐迈克尔·羽毛的“与遗产代码有效合作”一书，就如何做到这一点提出建议。您甚至不需要编写几个以上的单元测试就可以让它成为值得的工作，只需运行框架即可。

步骤0:将自动化的单元测试框架应用到代码中。

你不会想独自完成这件事吧？这是一个大项目，我希望你是一个高级技术团队的一部分，与你分担痛苦。你需要让他们全部买下这100%的东西。当你去找你的老板时，你需要他们的支持，你需要他们的专业知识来分享你的设计，你也需要他们在设计上达成一致。

第一步:召集一群人。

如果没有计划和目标，重构就不会有多大帮助。你是想把代码切成碎片，让模块变小吗？你要把代码组织成域吗？你会尝试将一些服务接口插入其中吗？你打算重构成n层体系结构吗？你和其他人认为需要做什么？你打算如何将这个设计和重构计划传达给SE？

第二步:让团队对最终状态进行一些初步的架构设计和规划。

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

所以，准备好回答你老板肯定会问的问题：“我为什么要问你？”你期望通过重构得到什么？你会把新特性的开发工作减少10%吗? 100%？您会提高代码质量/减少bug/降低支持成本吗？你能加快上市时间吗？多少钱？这会让你减少SE或承包商的人数吗？多少?或者你能在每个版本中增加更多的功能吗？还有一些负面因素:如果给你一年的时间进行重构，有多少特性会被延迟？再推迟多长时间？

第三步:做一些严肃的评估。

所以，既然你已经拥有了一个设计，一个计划，一个经济理由，并且你得到了技术人员的支持，回到你的老板面前，向他或她陈述你的观点。你会有一个更好的运气，比说“我们应该花20%的时间重构，一些人在互联网上这样说。”

我并没有为诸如重构、单元测试和文档之类的事情指定单独的时间。我只是认为他们是成品的一部分，而这项工作直到他们完成。

我怀疑是否有任何规范。

对于你的分解:大多数团队不编写单元测试，也不重构(直到某些东西中断或阻碍开发)。最常见的，重构时间分配是<1 %。

如果你对良好实践感兴趣的话.

作为开发过程的一部分，

• 重构可能是一个持续的活动。你看到了一个改进的潜力，你亲自分配了一些时间让事情变得更好。在这里，重构时间<5%。
• 执行常规代码评审。比如说，几个月一次。然后，您可以专门花几天时间让团队只检查他们的代码并对其进行改进。这里也<5%。