What does refactoring really mean?
I just stumbled across this cool essay on refactoring by Steve Yegge. I don’t agree with everything (there’s a comment near the bottom that I agree with a lot), but there’s some very cool stuff here about the “real” meaning of refactoring, and the importance (or lack thereof) of automated refactoring tools.
One of my reluctances about moving to something like Ruby in my classes (and, to be fair, my programming) is that I just love Fowler’s book (which I have read multiple times - I’ve taught a refactoring course three times now) and have found it and Eclipse’s refactoring menu to be life changing experiences. I move and rename things all the time now, and having those tools absolutely makes it easier.
That said, though, Yegge’s right that I often become so enamored of the trees of automated refactorings that I lose sight of the forest of simly trying to write clean code, and thinking carefully and sensibly about changing the code that’s already written. Clearly many people haven’t read Fowler’s splendid book, and for them refactoring is limited to what is, in fairness, the tiny (if wonderful) little world bounded by the automated tools in Eclipse or IDEA. That’s sad. And sometimes my course structures (especially in Software Design and Development) arguably encourages that. Which is far worse.
So back up, take a deep breath, and go (re)read Fowler’s book. I know I’ll have to rethink my concerns about the lack of refactoring tools in Ruby. I don’t think they’ll go away completely, but I’m sure they’ll be different, and probably lessened.
Then get back to work…
No tag for this post.