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.

Related posts

Those radio waves are flooding my brain!

You must protect yourself from those evil marketing rays
Back in Morris, it was pretty rare to run across another wireless network at the house. Every now and then you’d catch the edge of what was probably a base station somewhere else in the neighborhood, but usually we were the only visible network.

It’s just a wee bit different here in Colchester. Sitting here in the apartment I can see almost 15 different networks, and I wouldn’t be surprised if there are quite a few other “invisible” networks in the neighborhood.

Obviously designing tools to handle increasingly dense network environments is going to be a good career path for some time to come, as the sort of density we’re seeing here is going to more and more the norm. Coming up with innovative solutions to these challenges is also going to be the kind of thing that’s going to require some substantial computer science (and/or appropriate engineering) background (vs. web programming or a two year tech degree).

No tag for this post.

Related posts