Refactoring is not merely rearranging code statements. Refactoring is restructuring of the code starting from the architectural and abstract goal and then looking at how pieces of existing code would fit. Sometimes, that requires writing new code and tests. Refactoring by definition also means not breaking the user space.
I've never heard of any serious writer printing out their prose and cutting it and rearranging it. That just sounds absurdly unnecessary to me.
you are either using a different definition of architecture or this is wrong. Refactoring is bottom up construction. Most of the time when I see people frustrated or struggling (including myself) it's because they have forgotten this and need to take a break.
More information here: https://en.wikipedia.org/wiki/Code_refactoring
There are many goals in refactoring, specifically this section:
> Potential advantages of refactoring may include improved code readability and reduced complexity; these can improve the source code's maintainability and create a simpler, cleaner, or more expressive internal architecture or object model to improve extensibility. Another potential goal for refactoring is improved performance; software engineers face an ongoing challenge to write programs that perform faster or use less memory.
I was addressing OP's analogy to cutting pieces of written prose and rearranging.
Code is meant to be read by humans and only incidentally by computers.
A lot of architecture is just being clear about what is intrinsic complexity and what is accidental, be it cognitive or computational.
Writers definitely do this. Maybe not at the prose level, but for sure at the plot level and chapter level.
Take the section you are stuck on, print it out, cut it up into sentences or phrases, and just rearrange them until either it makes sense, or you figure out where you went wrong.
Rearranging code statements until something makes sense is exactly what refactoring is.