Rediscovering Refactorings

Michael Feathers wrote a blog listing some of the refactorings he would like to see in IDEs. Two refactorings in particular caught my eye, Extract Class and Introduce Parameter Object. In fact, these refactorings have been available for quite some time via a third-party plugin for IntelliJ IDEA called Refactor-J, from Sixth & Red River Software.

Introduce Parameter Object is great for simplifying a long parameter list by condensing several parameters into a single parameter object. This can be a great way to clean up your design to make it easier to use, easier to read and comprehend, and easier to maintain. Parameter objects can stay as simple value objects, or they can evolve into something more intelligent, as needed.

Michael's request also includes that any arbitrary group of variables (fields or local variables) could also be converted into aggregate objects. If it is possible to implement, I'd like to see this as well. It could potentially be a very useful refactoring, allowing you to quickly sketch out the collaborating classes your design may need. Just start with basic ints and Strings and build your object-oriented design from that.

If you regularly do complex refactorings, or if you just happen to want more power out of refactoring, I suggest looking into the Refactor-J plugin. It has about 20 extra refactorings in total. Also, for more 'personalized' refactorings, you can always use the built-in Structural Search & Replace feature of IDEA. It takes a little getting used to, and it cannot do all kinds of refactoring, but it is often the best way to make refactoring-like changes to your code that cannot already be made with existing refactorings.

At the end of his post, Michael asks for what he calls 'intelligent statement move'. Well, unfortunately what he's asking for is not likely to be seen for a while, but with a sufficient suite of unit tests, the basic Move Statement Up/Down editor command (Ctrl-Shift-Up/Down) is sufficient for most purposes. It can even move syntactically correct blocks of code (you can select sytactic blocks with Ctrl-W), or even whole methods.

Have you ever dreamed up any special refactorings you would like to see in your IDE?

Productivity Talks at JHUG Tech Day

Last Saturday I gave a talk at the Java Hellenic User Group, and I found it interesting that all of the talks given there had an underlying motivation of increasing productivity.

First was Dr. Heinz Kabutz, the famous Java Champion and editor of the Java Specialist newsletter, who had a talk called Productive Coder. It was a good talk to start the day because he gets you thinking right away about seeing things from a productivitiy perspective. For instance, his first major point is that most programmers that he has met cannot even touch-type without looking at the keyboard. It seems like such a minor thing, but by learning the keyboard so well that it is intuitive, it's just more productive since you don't have to spend your awareness on the keyboard and can think of the task at hand instead. Heinz' talk included many similar small-but-important ideas about becoming a more productive coder.

He also showed a demo of IntelliJ IDEA, emphasizing learning the keyboard shortcuts for an IDE (even I learned a feature -- column editing mode, Alt-Shift-Insert). I think learning shortcut keys is in many ways like learning a new language. Once you've learned one useful language, it's frustrating to try to get to the same fluency in another, unless you put some effort into it. This can make switching IDEs painful. Heinz mentioned the IntelliJ IDEA keymap reference card you can print out and stand up on your desk to help you learn the shortcuts (see here). He also talked about object-oriented principles and how to tame a jungle of legacy code with refactorings like Encapsulate Fields, to make fields private.

Tom Baeyens of JBoss/RedHat did a talk on workflows and process languages. Part of the motivation there is to simplify and automate communication between the analyst and the programmer, an attempt to increase productivity in this area. Tom has a great sense of humour and I enjoyed his talk very much.

Patrick Linskey of BEA talked about JPA (Java Persistence API), and how a big motivation is to simplify object-relational mapping, automating it, so you can think in higher level concepts of objects rather than tables. Of course the flexibility is there to use tables if necessary, but the real power of the spec is in ease of use and testability that the object abstraction gives you. Patrick was extremely knowledgeable, as we could tell during the Q&A.

Finally, my talk was on Tools for Agile Teams, focusing on how IntelliJ IDEA and TeamCity support agile development methodologies by helping developers stay in flow longer and more often. Flow is the highly productive state of mind when you're focused on a task and outside distractions seem to melt away. Most people in the audience reported that they had experienced the state of flow and also that they have experienced being frustrated by tools that interfere with flow by annoying distractions and context switches. I demoed some of IntelliJ IDEA's productivity features and gave an overview demo of how the TeamCity continuous-integration server can help increase team-level productivity.

Thanks to Paris Apostolopoulos and Panos Konstantinidis of the JHUG for organizing the event. It went very well and was quite enjoyable.

TheServerSide asks the right questions

Some IDE surveys are just simple popularity contests. Not this one. This survey from TheServerSide.com, has much smarter questions, and I'm really looking forward to the results!

For instance, instead of just asking which IDE you use, it splits it up into which IDE the organization uses as standard, and which IDE you personally use.

Some organizations impose a particular IDE on all the developers because of an 'organizational standard'. Such standards might be good for something like databases and servers, but I hardly think it makes sense to force a developer to use an IDE that he or she is not productive in. Developer productivity often trumps the relatively small cost-savings of standardization. If you save $1,000 a month by standardizing, but the IDE you choose makes your 10 programmers even 5% less productive, you're actually losing a big chunk of money there, since the lost productivity is closer to $5,000 per month.

Also, professional programmers like being productive and, given the choice, most of them would choose the one that makes them more productive rather than being forced to use an organizational standard. One of the interesting questions in the survey is "If you do not directly choose your IDE, which one would you prefer to use?" I definitely want to see the results there! I expect to see a lot of cases of organizations standardizing on a particular IDE, but some of their developers wishing they could use a different IDE. IDE choice is often a personal thing, and hopefully this survey will help people realize that.

Of course, the questions aren't perfect, although they are definitely a step in the right direction. One of the questions asks, "Which three features do you value most in an IDE?" While this is a good start, it completely ignores that things like 'productivity' and 'usability' are not features, but they can easily be the most important thing people value in an IDE. It is very common to hear fans of IntelliJ IDEA say things like, "There's no particular feature I can point to, it's just that all the features just seem to work better." I hope to see surveys in the future that tackle the importance of intangibles like usability, intelligence, and productivity.

Check out the survey here.