Refactor Slack

Have you ever been ready to refactor some object-oriented code, then had second thoughts as to whether you'd thought it all through (does the benefit of the refactoring exceed the cost)? Then after getting involved in other things and forgetting about it, rediscover that refactoring but see it in a new way. Where you previously saw two similar mechanisms in need of factoring, you now see a perfectly fine starting point for the base class and derived class you want to build. Now you're fine with not having gotten that early factoring done. You might say you've benefitted from RefactorSlack.

This happens to me all the time. I consider it as important to doing quality work as is flow. Refactoring requires you to change your focus, and if you don't give yourself enough time to do that then you'll only get local optimizations, not global ones. When you've expressed your work, step back. It's the GoPattern of tenuki: look for the big point. The work has its own grain and rhythm, and if you rush it, you spoil it. --PeterMerel

I, too, often have a good (or better) idea after reflection or after thinking about something else. However, "thinking it all through" isn't necessary that often when refactoring. Refactoring is about moving behavior to the object it belongs on, removing duplicate code, and so on.

And don't forget that all the reflection in the world won't come up to a moment of reality. Try that refactoring. If it's better, leave it in. If it's not better, take it back out. Pushing this way and that will help tell you what the objects really want to do. Imagining is good: doing is good too. --RonJeffries

I appreciate that perspective. Action often trumps thought in my book as well. But I find an aptitude for living with unfactored code of equal value to an aptitude for undertaking a refactoring without a complete understanding of it. The important thing, to me, is not how well-factored code is, or whether I know all the factoring steps required to make a change, but whether I can see clearly the benefit of that transformation versus doing nothing. --ScottJohnston

Yes, it can be valuable to be going for a particular benefit. One thing that Kent teaches, if after only N years I've gotten it, is to see the sign that a refactoring is needed, and to know the steps to remove it:

Multiple sends to the same object not self => create method in that object's class.

The refactoring almost does itself in a large percentage of the cases now, even for us eggs. When you sit with him, you perceive that he really isn't envisioning anything at all, he's just observing differences from "quality" and applying standard transformations. It's very zen, very flow. Relatedly, see ToAyoungExtremist. --RonJeffries