“任何时候都可以重构”，如果这样回答太过于宽泛，因为总有那么一些时候重构的 ROI （投入产出比）并不高，设置与对重构还不那么熟悉的开发者相当于什么都没有说。
所以整理了下日常开发中进行重构的时间点，从而来帮助提升开发效率和重构效率。
如上图：日常重构的时间点可以分为上述三个时间点。
Tasking 之后，开发之前进行重构；
开发过程中，进行小步重构；
修复 Bug 时进行重构；
01 Tasking 之后，开发之前进行重构
Tasking 指的是任务拆解（如果不熟悉，可以看这个视频 或者 看这篇文章）,拆分过程中有可能会涉及到在原来的代码上进行添加，因此可以在Tasking 过程中先了解原来的代码，并将原代码中发现的坏味道标注出来列在 Task 列表中。
因此在完成 Tasking 之后，其实就是一个时机来进行重构。当然有些重构并不是一开始做，而是随着实现逐步引发小步重构。但是 Tasking 之后考虑何时重构绝对是一个事半功倍的时间点。
另外，在干净整洁的代码上添加新的代码，也是更加容易的。
02 边添加新代码边重构
Simple Design 在实现业务代码时给我了我们很好的指导，能够在实现代码的过程中，保持代码结构的简单。除了技术上的重构也让产出的代码和业务贴近。
自上而下的开发方式，能够帮助我们维护好代码的层级结构。自上而下的开发方法过程中也需要 小步重构，来让代码在逐渐添加的时候，同时维持整洁。
重构时有个“事不过三，三则重构”的原则，指的是并不是每个 Smell 都需要一上来就聚焦消除，而是随着重复障碍、重复代码的出现次数增多而决定重构的辅助原则。其中的三次是个概数，指的是大于等于2次，至于第几次进行重构，取决于你遇到的实际问题，可以延迟解决，也可以当机立断立刻解决。
边添加代码边重构，还能够减少上下文切换的时间。当我们聚焦在一小段代码时就可以重构，由于上下文边界有小，很容易出现重构思路，并采用响应的手段。避免形成大段脏代码之后才进行一次重构。在重构技巧上多加练习就能达到小步重构的能力。
03 修复 Bug 时重构
前面介绍的是添加代码开始之前重构来让后续工作更加高效，添加代码过程中重构，保持开发效率的同时，时刻守护代码设计。还有另外一种场景，就是修复 Bug。
修复 Bug 时，很容易由于修复而导致原本的设计收到破坏，如果原来的设计不合理那么我们当然应该修改它，如果原来的设计挺好，修改 Bug 的时候我们也应该进行重构，避免让代码因为后续的修改而逐渐腐败。
另外一种场景时 Code Review 之后如果发现了某些坏味道或者设计缺陷，或者更好的实现方式，可以在 Code Review时利用 Todo 插件，编辑需要重构的点、需要重构的原因、重构的目标，并在当天将CR时发现的问题进行修复。这个修复Bug 类似，需要时刻保持重构的习惯。
总结
如果你对重构技艺已经非常精湛，并且能够灵活控制重构对代码添加、修改的影响，那么从各种场景来看“任何时候都可以重构”又是正确的，因为此时：能力决定了生产力
