什么时候重构，在很多组织当中并没有一个明确的准则。
有的开发人员想要对代码进行优化提出重构的时候，往往会被领导要求证明这是不是一个合适的重构时机。可是如果真的要等到开发人员完全证明了修改的合理性之后才去进行重构，那么可能要等待很长时间而推迟代码重构往往会使重构变得更难执行，因为要修改的代码已经变得更加复杂，并更深地嵌入到其他代码中。这样只能会使重构付出更大的代价，或者不进行重构而忍受坏代码的表现。
另外一个极端则是持续重构。这是一个看似合理的做法，也被认为是一种“最佳实践”。因为它只是给出了一种愿景或期待——鼓励重构，但依然给出何时重构的准则。
如果每次重构都需要开发人员提供合理性的证明，那么只会限制重构的进行（或者让重构只能暗地里进行）。
只有我们真正理解了重构的意义是为了实现更好的软件，始终坚持把“通过重构得到更深层理解”作为开发工作的一部分，我们才能建立合适的关于代码重构时机的准则。
代码重构的最佳时机可能是：
软件设计没有表达出对软件需求的最新理解；
用户重要的需求没有被很好地实现，而且你已经发现更好的实现方法；
开发人员发现了一个能使某个重要的功能设计变得简单、灵活的方法。
重构虽然可以帮助我们实现更好的软件，但并不意味着可以随随便便进行重构。不要只为了引入一些炫耀技术能力就进行重构。
万事都不是绝对的，但如果某个重构对我们有利，那么不妨在这个方向上大胆前进。
这正是：
重构虽然有帮助，仍然不能随意行
重构时机建准则，意义重大方可做
参考文献：领域驱动设计：软件核心复杂性应对之道（修订版），[美]埃里克 埃文斯，译者：赵俐等，人民邮电出版社
联系客服
