Here I am tending to my blog on the bus. I wasn't really planning on it. I was just checking my email. I get email, among other occasions, when someone or something posts a comment to this blog. My mail this morning suggested that a spambot was posting spam comments to this blog. So here I am, cleaning spam. As long as I'm here, I guess I'll post a Book Report I've had sitting ready for a few months. It's about re-writing software. Like hopefully someone will re-write some of blogger's anti-spammy stuff so that bots can't break CAPTCHA anymore. That would be awesome. Actually, this book isn't about that kind of programming, not about changing how programs behave. It's about changing programs so that they behave the same.
If you're a computer programmer, you've probably heard of this book Refactoring. Everybody talks about it. Everybody talks about Knuth, too, but nobody has read him. (I started to read Knuth, but bogged down when I was reading about his example machine architecture... what was it, 13-bit words? Yeah, yeah, I've heard that the new editions will feature a more modern architecture. I'm sure I'll give them a try eventually. Anyhow.) Reading Knuth wasn't easy. But reading Refactoring is easy.
Parts of it were too easy. I eagerly read the catalog of refactorings. I gobbled them up like popcorn. "Oh, I can see how to apply this refactoring, and now I feel clever," I chuckled to myself. But I was reacting like some silly student who still has a favorite data structure--it was too easy to get swept up by the catalog of refactorings, to forget that each refactoring has a purpose.
I'm doing my best to forget the list of refactorings. Instead, I want to remember the list of "code smells"--things to look for in my code. Symptoms of problems. Often, to recognize one of these suggests the refacto... the edit by which one may purge it.
Alternative classes with different names, Comments, Data class (struct w/few methods), Data clumps, Divergent change, Duplicated code, Feature envy, Inappropriate intimacy, Incomplete library class, Large class, Lazy class (class w/little functionality; perhaps can be absorbed into something else), Long method, Long parameter list, Message chains, Middle man, Parallel inheritance hierarchies, Primitive obsession (reluctance to use objects to represent, say, int values), Refused bequest (subclass overrides most of parent), Shotgun surgery, Speculative generality, Switch statements, Temporary field.
Looking them over, most of these look like problems with poorly-architected OO. There's a temptation to toss out OO--look at the mess it's brought. But then, I do like being able to associate functions with the data they act upon. I like it most of the time. And, as the saying goes, "I can write Java in any language". Don't toss the baby out with the bathwater. Moderation in all things.
Maybe I should turn on moderation for comments on this blog. Hmm.
Labels: book, programming