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…
First, I haven’t read the book, but not because I haven’t wanted to. I just haven’t had the opportunity yet.
From my perspective, refactoring isn’t just for moving from bad code to good code. It’s also critical in an agile environment for moving from previously-good code to newly-good code when requirements change.
Reading the linked article has made me move reading Refactoring up the priority list.
I do totally recommend Fowler’s book. I think the first five chapters (everything up to the big list of recipes that forms the bulk of the book) are as fine a piece of writing on programming out there, and totally worth the price of admission on their own. Totally changed the way I think about programming.
I like your comment about refactoring helping move goodness when requirements change. Change is when so much code begins to degrade, and refactoring gives you tools to help you maintain the quality of your system as you move in that new direction. Even cooler, it opens up the doors to even make improvements while you’re doing it, especially since you probably understand your code better having had more experience with it.
Good luck with the book!