[saryant]

A rule of thumb that I try to follow (but often neglect) is to keep changes either sweeping/shallow or narrow/deep. So if you're refactoring a module and that has implications across the codebase, don't try to make a deep change to the business logic at the same time.

Keep those tasks separate.

[jmsaucier]

I find that I will be making a change, notice a refactoring, and then get lost in the rabbit hole. I try to keep a pad of paper by me at all times now, and if I notice something, then I will make note of it, but keep moving with what I was doing. Then after I'm done, I can revisit the notes that are on my paper. Right now, a lot of those become backlog techdebt items that will get fixed in the future.

[bcbrown]

One approach I sometimes take is to make the refactoring in one commit and the change in another. They can go into the same PR (within reason), but they're clearly separated out.

[funkymike]

This is the approach I try to take. It requires discipline but it has helped on several occasions.

The biggest benefit is that it makes code reviews easier for others because the reviewer can step through each commit. This makes the refactoring changes much more obvious.

Splitting the commits also makes it much easier to roll back a functional change that goes wrong or isn't needed while still keeping the refactoring improvements.

[pelhage]

The problem I deal with is that if I see something worth improving that doesn't get fixed now as I see it, unless it's a really significant issue, the code won't get improved down the line

[konamicode]

At work, we often create tickets to deal with such things and have epics dedicated to "code gardening". These are often addressed on a Friday afternoon or at other times when one feels their productivity is especially low.