The best way I've found - like you say - is to not treat refactoring as a separate task. It should be part of your normal process. I would also suggest not working to deadlines, or doing overtime - neither of these are conducive to good work and should be avoided
You should treat it as a separate task with it's own acceptance criteria and testing though, here's a great post about this advice:
Probably the fundamental observation in Fowler's Refactoring book is that you are much better off separating changes that affect code behavior from changes that don't. Those in the latter category, we call "refactoring". If you mix these changes, you mess them up - so don't. You can switch back and forth between coding and refactoring modes, but don't do both at the same time. Because if you try to, you won't know what you did wrong.
If you try to introduce a behavior-modifying change, and the behavior doesn't modify: you did something wrong; review it and fix it. Maybe just roll it back.
If you try to introduce a refactoring, and the behavior does modify: you did something wrong; review it and fix it. Maybe just roll it back.
You can't make that simple assessment if you attempt both changes at once. Nor can you, if you don't have unit tests. Write them. And do one thing at a time.
The best way I've found - like you say - is to not treat refactoring as a separate task. It should be part of your normal process. I would also suggest not working to deadlines, or doing overtime - neither of these are conducive to good work and should be avoided
You should treat it as a separate task with it's own acceptance criteria and testing though, here's a great post about this advice:
softwareengineering.stackexchange....