This topic contains 17 replies, has 2 voices, and was last updated by 
-
Posts
-
This is where I was hoping people would discuss the Essential Refactoring blog entry. The current version lives here:
Provide some motivation for this change. Why are you separating out something into another class?
Experiences differ. I’ve found many valuable refactorings to be those that are not provided automatically (at least in a straightforward way). E.G. Creating a HorseEntry class for the HorseRace (see my TDD slides for an example). Perhaps there is a way to do this automatically. It’s a tradeoff between the time required to figure it out and just doing it.
Thank you.
Isn’t “so that I can test it once instead of each time it’s used” enough of a motivation?
Your second paragraph confuses me. Did you get the impression that I was saying the automated refactorings where the only valuable ones?
As far as the tradeoff thing goes, I don’t think that’s true. Unless you’re right at the tail end of your career – like retiring in a few months – a policy of learning how to use the automation will pay off.
It doesn’t save you typing, obviously. The idea that the typing is what automated refactorings save is the same kind of naivete that makes people think a developer who isn’t spending his time typing isn’t working.
What automation saves you is thinking and errors. The same way that calling a method saves you from having to think about how that method works – you only need to focus on what it does. That’s also true of automation.
Extract method is just extract method. There are no steps for me; not ever, nor should there be. I just tell the computer to do the boring stuff and keep thinking about what to do next.
Regardless of context, whether it’s automatic a database build or a refactor, lifts our minds out of the muck of minutae and implementation so we can focus on intent. When’s the last time you typed something like this?
push AX push BX call analytics_averageRight? For me, it’s been long enough that I’m not even sure if I typed it right. analytics_average(x, y) allows me to focus on the fact that I want a method call rather than how the call is made (let alone focusing on what it does rather than how it does it).
It’s all the same thing…because everything is like everything else.
I wonder if there’s a podcast in this kind of debate…
I’d like to know what you think the thesis of this blog entry is, Ken, if you have the time.
I’m not anti-automation. I’m just saying there are cases where a useful refactoring cannot be done with automation. Automation does not save thinking. You need to think as to what to extract. Just as automation cannot convert requirements into implementation (for the most part). You need thinking.
The message I get is to make a recovery version for a large scale refactoring.
I didn’t think you were anti-automation. I thought you were getting that my message was “you should use automation” – which it is not.
What you are hearing as the core message is part of it. It’s more like “this is the process for refactoring regardless of scale or automation.”
What is missing from the blog entry that might have helped that message come across to you, Ken?
Ken, I really do hope to hear what you think I could add to or change about this blog entry to make the message more clear.
Scott, was the message clear to you when we were collaborating on these?
Moving a method out of a class to make it testable appears to me to be more clunky than just making it protected. This is a viewpoint. So the example doesn’t seem relevant to me.
You state “A lot of people who want to “refactor” think primarily of their ultimate design goal. I think what’s happening is people are trying to race to the place they want to be”.
I don’t think that this is as bad as you make it out to be. You may need to spend some time in not-green in order to do some non-automatic refactorings. It’s up to the individual to decide how long they are comfortable with that.
Moving a method out of a class to make it testable appears to me to be more clunky than just making it protected. This is a viewpoint. So the example doesn’t seem relevant to me.
I made it more clear what my motivation is – making the method testable and (more importantly) mockable.
I know you can mock stuff with protected methods but that’s inheritance to specialize and I don’t know why people would do that when they have the alternative of composition.
I don’t think that this is as bad as you make it out to be. You may need to spend some time in not-green in order to do some non-automatic refactorings. It’s up to the individual to decide how long they are comfortable with that.
I disagree with your use of the word “need”. This is a great example of where subjectivism simply does not apply. Objectively, you don’t need to spend a long time between green states. You may choose to and you may want to do that. You may even be comfortable with that. You don’t need to do it. Not ever.
Even the rote manual refactorings we show in our STDD course demonstrates this essential way of working. You always get back to green as fast as possible. If you have two paths that lead to the same endpoint, you choose the one that gets you to green sooner even if it looks like it will take longer in the long run. This is because the path with the shortest maximum green-to-green time tends to take the least amount of time to get totally done.
If I ever bothered to read the Refactoring book, I’d wager that I’d find all the rote refactorings are expressions of this process.
Did I fail to communicate the thesis or do you just not agree with it?
A little of both.
So you actually believe that you sometimes need to spend a long time in a non-green state? I’ve not no response to that that is in the scope of this blog.
How could I have made the thesis clearer to you?
I would not discount the possibility. I would not get hung up on the word “need”. As you suggested, it could be “choose”.
What is your thesis for this blog?
The thesis is that refactoring is working in small, validated, behavior-preserving changes with a way to abort if something goes wrong.
You must be logged in to reply to this topic.