Circular Refactoring Circular RefactoringDoes this happen to other people? Why does this happen? What in the code makes for a circular refactoring? Is there a particular structural error that leads to this scenario? Or are there problems where this just happens more often?
What is it specifically that you are refactoring for? Is it the same goal/criteria each time, or do you change that as you go along? Are you mostly keeping the dependencies and relationships pretty much the same and just juggling and cutting and pasting around that?
I've found myself going around this loop when I can't keep the requirements in my head. I satisfy A, make a change to satisfy B, discover a forgotten property of A, discover a forgotten property of B, and so on. One can satisfy nearly contradictory constraints by following this path around a few times, though a better approach is to shed some requirements, especially those self-imposed.
It can be hard to let go of readability or simplicity as a requirement, especially when you think that is why you are refactoring. A funny quirk of these mind-size based requirements is that they are rarely satisfied by trying harder. -- WardCunningham
Ward, can you (or someone else) clarify/expand that last sentence? It's intriguing, but I don't think I fully understand it.
I'd like to try. We're putting forward these base (fundamental) heuristics (for example, simplify, make it readable, refactor towards these ends). These approaches work when you keep them in mind as you go about your day. However, as in many good things, if too much stock is put in the way, it eludes. The harder you try, the harder it gets. -- MattSimpson
This sounds a lot like a physical system oscillating between two local minima. Apply a larger impulse (kick the code) to see if the system will make a larger excursion and discover a lower energy state. -- MichaelNygard
This page mirrored in WikiPagesAboutRefactoring as of April 29, 2006