If you could have only one refactoring, which would it be? Which refactoring could you least afford to give up?
To me the obvious answer is the rename refactoring. It’s an activity that I do very frequently. In fact, the way I code is dependent upon my ability to do a rapid rename.
I try to follow Uncle Bob’s mantra “never be blocked” at even the smallest granularities. I won’t stew for more than a few seconds to derive a name for a class, field, method, or other identifier. Instead, I type. If my brain is really frozen, I’ll surge forward by typing an “x” or the word “something.” No worries–I usually think of a better name shortly thereafter. I then do a ctrl-1/rename, type the new name, press enter, and Eclipse completes the job for me very safely and quickly.
The name isn’t final at that point. I’ll continue to update an identifier’s name as my understanding of what it represents gets refined (or changes).
Recently I committed myself to working more in-depth with Groovy. I’m happy with its improved simplicity, consistency, and expressiveness over the tedium that is Java. As always, I spent a while using Groovy’s bare-bones tools (groovyc, groovyConsole, etc.) so that I understood them enough to survive if I had to. Done enough of that! Now I’m looking to my productivity experience by introducing an IDE, so I downloaded and installed the Groovy plugin for Eclipse.
Harumph, and that’s even after ignoring (a) a couple bizarre errors that I received because I hadn’t forced a clean and (b) the obtuseness of the exceptions. No, the big harumph is that there are no ctrl-1 or refactoring options anywhere to be found. I’ve heard IDEA is better (and hope to try it out here soon), but as I understand, the rename challenge will never be completely resolved: safe rename refactorings require type information. You can provide that in Groovy, but figure on most developers not bothering.
And for now, the Eclipse plugin isn’t even trying. I created a private, typed field–something for which a refactoring operation could be very safe–but now I can’t change its name without resorting to search/replace. The fact that I may need to discard my newer programming style of “continual rename” makes me feel dirty.
Even with some forethought, programmers will always choose some names that end up less than ideal. And since developers are notorious for not changing things that might break, the poor names will remain as long as the IDE can’t do it safely. Maintenance costs will be higher.
The main point of my post is that after years of using a strongly-typed language, I am now resisting languages like Groovy and Ruby to an extent. Not because I’m worried about the defects that could happen at runtime that wouldn’t otherwise-my use of TDD generally means that’s not an issue. Instead, my complaint is about lack of productivity, and worse, the decreased amount of refactoring that will likely result.
The question is, do benefits accruing from the increased simplification of the code outweigh the negatives of more difficult refactoring?
Comments
chrismo June 23, 2008 at 04:42pm
[Full disclosure: I may have an interview with you soon, so I may just be sucking up here with my comment.]
I’ve collected a few links and thoughts on refactoring languages like Ruby at my blogki, and sometimes share similar concerns.
Some counter-arguments I believe I’ve heard on this topic … and may or may not agree with:
– Ruby doesn’t require as many refactorings as a language like Java does. It’s easier to morph your designs without outside aide. Much like the GoF Design Patterns is mostly moot in Smalltalk — you don’t need a design pattern for something that is second nature.
– Refactoring was invented in Smalltalk … why worry about refactoring tools for Ruby? They’ll come.
– … (well, I’m tapped out. I guess I didn’t need a list here.)
I like your post, though. I’m very fond of my friend “Call Hierarchy” in Eclipse — esp. when working through a mess of code. It’s faster to analyze call paths then to try and make some changes and then wait for a test suite run to tell me if I went wrong (obviously, both are valuable, though). Of course, the codebase should probably make more use of coding to interfaces and not have such a long running test suite … but … such is life.
Ramble off.
Chad Johnston July 24, 2008 at 01:03pm
I know first hand how anal you can be about refactoring, so I understand what you’re talking about. I’ve just been able to introduce Groovy into our environment and have been running into a lot of the limitations of the Eclipse Groovy support. I’ve been pleasantly surprised at IntelliJ’s Groovy support, which includes refactoring. It’s not a perfect solution, as I still prefer Eclipse for my “normal” development, but it’s a decent stopgap until Eclipse’s Groovy support becomes more first class.
