重构代码通常是应用更好的适应模式，应用编码约定或提高性能的问题。另一方面，重构需要花费时间并且会引入包含新错误的风险。
应该使用什么标准来确定是否重构代码单元？
我的猜测是：
还需要评估哪些其他方面，是否有用于确定此问题的公式或系统？我正在寻找科学或至少系统的方法。
编辑：我认为这个问题与我实际想知道的有点不同。更确切地说：一旦找到可能的代码味道，您如何确定优先级并进行通信？是什么让一个重构比另一个更重要/更紧急？
答案 0 :(得分：1)
当您应该进行重构时，有许多不同的情况和原因。例如，你的方法做了很多事情。如果方法做了很多事情，那么测试就很困难，所以你需要分解成更小更简单的方法。
通常你应该保持一个班只负责一件事，如果不是，那么就是重构的时候了。
此外，如果方法有很多参数，那么可能你的方法是错误的类，或者可能是以其他方式进行优化。
如果你有很多if-else条件，那么你可能应该采取一些状态/策略模式来消除if-else。
在很多情况下你应该开始进行重构，最好的是首先阅读“重构马丁福勒”一书。在本书中，他涵盖了很多情况，我强烈推荐它。
答案 1 :(得分：0)
当业务需求发生变化并且很难将新的软件行为纳入代码库时，这是重构的主要标准。！ 目前，它成为高优先级，因为它将阻止我们实施所需的更改。
首先要容易更改，而不是容易更改;）
何时重构：
至于何时不重构，我可能会说，为没有经过验证的产品市场适合度的初创公司编写代码时。您的项目可能很快就会结束，因此在使其投入使用之前，使其在技术上具有可扩展性是什么。