Stop hand-refactoring and learn your automated refactoring tool

Refactoring is the lifeblood of a nimble codebase, but we need to stop hand-refactoring via Ctrl-C/V and start using our automated refactoring tool.  Prepare to be convinced, then watch in amazement as you memorize your favorite refactoring tools’ keyboard shortcuts in two hours flat – and remember them forever.

You need an automated refactoring tool

Refactoring without tests is dangerous

Refactoring without tests and without an automated tool is like walking a tightrope over Niagara falls without a safety net - with your product and entire team standing on your shoulders. Don’t be that guy.

A good automated refactoring tool allows you to refactor without tests. Without w-w-what?! Unlike us, automated tools aren’t afflicted with momentary lapses of attention or judgement, nor the tendency to flip-flop on boolean logic. They just do what they were programmed to do, usually extremely well. The upshot is that you can actually refactor without any tests in place. Now I don’t encourage refactoring without test coverage, but sometimes it’s necessary.

Imagine landing in a legacy codebase with no test coverage. (Noooo!) Usually legacy code is not testable out of the moldy box. You’ll have to break dependencies, decouple components, and introduce “seams” in order to get your unit tests in place. Once coverage increases, you can refactor with a bit more impunity, but until then, use a refactoring tool for every single change. For a deep dive into the subject, see (affiliate link ahead!–>)Legacy Code , by Michael Feathers.

Many devs aren’t using an automated refactoring tool - Why?

Many times I find myself pairing with a developer and watch them “hand” refactor a section of code using Find and Replace, or even just their eyes. These are often incredibly talented and productive developers, which really drops my jaw. It’s humbling really, like when Joe Satriani comes over for dinner, picks up your kid’s $49.95 Wal-Mart special and idly picks out a soul-piercing melody that pulls a tear from even stern old uncle Ernst. Oh yeah, and the guitar is missing a string. twang! True, the tools don’t make the developer, but they can make them a better and safer developer.

Why aren’t these developers using the automated refactoring tools at their disposal? Sometimes I’ll pipe up and say, “Hey, wanna see something cool? Undo that and press Ctrl-R-M, to extract that block of code into it’s own method…” “Whoa, that’s cool!”, they say. But next time we’re pairing together, they’re back to copy and paste.

Why is it so hard to learn a tool’s automated refactorings and their shortcuts?

Refactoring tools have a steep learning curve

Oh, the jargon!

The learning curve for automated refactoring tools is fairly steep. First of all, you have to learn the terminology. Most of it comes straight from Martin Fowler’s book, Refactoring. If you weren’t formally educated, or haven’t read the book you may not immediately know what a given refactoring does when you go spelunking through your IDE’s refactoring menu. With your head buried in the code, who wants to stop and search for a refactoring that does who-knows-what?

So many shortcuts, so little brain…

In the typical IDE, refactorings are difficult to access unless you know their shortcut keys. They’re entombed somewhere in the labyrinthine menu structure, requiring another scouting expedition, taking your head out of the code, and into the editor. Shortcut keys in general are notoriously difficult to learn; there’s so many shortcuts, and their usage infrequent enough, that they never get drilled in your head like good ol’ Ctrl-C/V.

Confronted with such a steep learning curve, it’s no wonder so many of us just sigh in exasperation and revert to copy/paste hand-refactorings. There’s zero jargon, only 2-3 keyboard shortcuts to remember, and everything is right there in front of you. So the question is: is taking the time to learn your refactoring tool worth the investment?

Learning your refactoring tool is worth the investment

<img src="https://imgs.xkcd.com/comics/automation.png" alt="The pitfalls of automation">

Developer’s are famous (notorious?) for automating away repetitive tasks. But as this xkcd shows, not all investments in automation are worth the eventual payout.

Learning your editor’s refactoring tools will require an initial investment in time. However, the long-term payoff is worth the effort. You’re much less likely to inject a bug when using a good automated refactoring tool, and having the most common refactorings at your fingertips lowers the psychological barrier to writing clean code. With a few keystrokes, you can experiment with alternate refactorings and see the results right in front of you: “Should I extract this section of code as its own method? Let’s see how it reads. Ctrl-R-M. Done. Mmmm looks good. What about this section? … Or, this method isn’t doing much for it. I’d like to inline it with its calling method. Ctrl-R-I. Boom, done.”

How to learn your automated refactoring tool

Learn the theory of refactoring

Sometimes Devs are averse to trying their IDE’s automated refactorings because they aren’t comfortable with the terminology. That’s understandable. The first step is to educate yourself about the underlying theory of refactoring. I wrote a Refactoring Primer  a few years ago that should get you started with the basics. But don’t stop there. Definitely read Refactoring^{(affiliate link)} , by Martin Fowler. After that, read Working Effectively with Legacy Code^{(affiliate link)} , by Michael Feathers. As you read, take note of the terminology used to describe each refactoring discussed in the books. You’ll see it used in popular refactoring tools.

Once you understand the basic refactoring jargon, the terms used by your IDE will make a lot more sense. You’ll be giddy to try every single one of them – do that! Don’t refactor just for the sake of refactoring, but do experiment with the refactorings offered by your tool, so that you know when and where they’ll work for you.

Learn your refactoring tool’s keyboard shortcuts

Hunting for a refactoring in a deeply nested menu structure isn’t good for maintaining your state of flow. Fortunately, most automated refactoring tools pair each refactoring with a keyboard shortcut for quick access, allowing you to stay in the zone. Wait, did I say “fortunately?” How can anyone possibly remember all those shortcuts?

You can learn the shortcuts, even hundreds of them, and you can do it within a few weeks. The key is analysis plus spaced repetition learning via Anki. This is the subject of my next article, Keyboard shortcuts! Quickly learn &rsquo;em &mdash; and never forget .

Call to action

Fellow developers, refuse to refactor by hunt-and-peck, copy-and-paste. When tempted to revert to your old ways, remind yourself that refactoring without an automated refactoring tool is dangerous. Learn the tools. Eventually, you will experience the true joy of refactoring — that oneness with the code, bending it to your will, sculpting it to match the domain, melding it toward the path of maintainability — safely, and efficiently.