我支持“潜入重构”的方法，这应该是重构的最初目的。仅仅为了“清理代码”而进行重构可能是一个不好的想法。这意味着你在没有真正原因的情况下进行更改。重构的定义是修改代码但不打算修复错误或添加功能。如果你遵循KISS原则，任何新功能都将需要至少一些重构，因为第一次你并没有真正考虑如何使系统尽可能具有可扩展性。
如果你正在处理一段代码块，大多数情况下是因为有一个需要更改该代码块的错误修复或新功能，并且重构是在更改之前为了使其更容易进行，或者在更改后整理结果。无论哪种情况，你都可以将重构与该错误修复或功能关联起来。
让我们来看看每个选项：
如果您认为原始代码存在安全风险或可能导致崩溃或不稳定，请编写一个简短的错误报告，概述风险，然后修复它。
基于功能请求重新设计代码可能更难。但是，您可以使用有效的功能请求来完成此操作，这将引导我进入下一个要点......
如果存在有效的错误或功能，请声明必须略微更改函数x以修复错误或添加功能。
这似乎表明通过改进应用程序来进行自我发展是不允许的。开发人员应该被允许，如果不是的话，就鼓励探索新技术和技术。
也许您可以在相关会议上讨论您的改进，并给出令人信服的理由说明为什么应该进行更改。那么至少您将获得管理支持，而无需通过其他方法偷偷添加代码。
如果你在一个有这种不灵活（而且荒谬）政策的地方工作，最好的解决办法是找另一份工作！
