Crossing Refactoring's Rubicon

Approaching The Rubicon

In 1999 a number of people contacted me about tools they were working on that supported refactoring. I keep a list of these tools at www.refactoring.com (there another list on the wiki). Although refactoring.com is hardly a hub of the web people clearly wanted to be listed amongst the refactoring tools.

However I'm not at all interested in reviewing refactoring tools on the site. There are many things that interest me, but reviewing software products is not one of them. I'm happy to keep a list, but reviews I'll leave to others.

Having said that some minimum standards are in order. A couple of vendors wanted me to mention their tools. I looked at their “Move Method” capability, and found that although they could move a method body from one class to another, they didn't alter the callers. As a result a program no longer compiles after applying the transformation: hardly semantics preserving!

There were tools that were more honest about their capabilities. A number offered the ability to do various kinds of renaming, such as Rename Method. Now providing the callers are adjusted, renaming counts as a refactoring - and a very useful one to boot. Also several tools support moving a class and, since repackaging is a pain in the neck in Java, this is a very useful refactoring.

All of these were encouraging signs. But even so I was not seriously excited. All these were steps, but there was a key barrier to cross.

The Rubicon

The kinds of renames that I've been talking about require some analysis of the software, but it's fairly shallow. You can do renames with without going too deep into the structure of the program. Indeed many people do renames manually by editor search/replace or through simple regular expression based scripts. To go the full extent into refactoring you actually have to analyze and manipulate the parse tree of the program, as John and Don describe in the book.

A refactoring that needs this capability is Extract Method. While one reviewer on amazon described this as merely cut and paste, Extract Method actually requires some serious work. You have to analyze the method, find any temporary variables, then figure out what to do with them. The analysis is not something you can do by regular expression manipulation. It requires some careful work.

That's why I see it as a key refactoring. If you can do Extract Method, it probably means you can go on more refactorings. It's the sign that says “I'm serious about this”.

Crossing the Rubicon

The first thing that made me think there was a serious attempt at crossing the Rubicon was in mid-1999 when I was contacted by Instantiations. For those that don't know, Instantiations is one of the most highly regarded names in OO circles. Born out of the Portland Smalltalk community the company was one of the major parts of Digitalk and did a lot of serious work in Smalltalk. Since then they've moved onto to Java and developed several products, including Jove - a native compiler.

So when Instantiations said they were starting work on a refactoring tool (then codenamed Alchemy - now called jFactor) I was excited because I knew they had the understanding to do a good job. I was even more encouraged when they said that the first refactoring they were going to tackle was Extract Method.

However they weren't the first across the river. That prize goes to X-ref: a plug in for emacs developed by Marian Vittek. To be honest this didn't have a big effect on me as I don't do my Java in emacs. Also x-ref's extraction has some limitations and Marian's outfit is a small operation. But it got there and is well worth looking at if you use emacs regularly.

If X-ref was the rowboat crossing the Rubicon, Instantiations crossed the river in style. Their tool jFactor supports a nice list of refactorings, including Extract Method, in a very professional looking tool. jFactor is available as a plug in for IBM's Visual Age for Java. Now extract method is just a case of select the code, choose the menu item, and type in the name. Refactoring is here in style.

jFactor was enough for me to consider January 2001 a banner month for refactoring, but I got a pleasant surprise. For a while IntelliJ have been building an IDE for Java that was liked for its Visual Age like searching capabilities. They added various renaming capabilities to the tool which made it a minor favorite on the sixth floor here where we were unable to use Visual Age. Then in January I got a surprise email - their IDEA tool now supports Extract Method.

Going Further

The January flurry is exiting for me, as I'm convinced that refactoring tools are going to make a big impact on software engineering. Indeed I've called John and Don's Refactoring Browser the biggest step forwards in development tools since the IDE. I also hope that now the Rubicon of Extract Method is crossed, more refactorings will follow. Certainly I urge you check out these tools and try out their refactoring capabilities.

As a side note, I'm not going to provide reviews of these tools. Doing a proper review is too time consuming. I do keep in touch with these vendors and will be doing what I can to help their developments. However I would be interested in seeing feedback on these tools and will continue to maintain a list on refactoring.com information about refactoring tools. I'll also post tool news on that site as the vendors share it with me.