When software developer and industry thought leader Martin Fowler first approached the topic of refactoring in his book — Refactoring: Improving the Design of Existing Code — it was the late 1990s and early 2000s, with the original edition of the book coming out in 2000. Since then, a lot has changed in the software development world, but one thing has remained the same: The need for refactoring. According to Fowler, refactoring is a technique in which teams improve their codebase by applying “small behavior-preserving transformations.”

Since the first edition of his book was written about two decades ago, Fowler has decided to revisit the topic with the second-edition release of Refactoring. SD Times spoke with Fowler to learn more about his book and the remaining importance of refactoring.

SD Times: Why did you think it was necessary to revisit this topic?
Fowler: The book has been around for nearly two decades, and it does show its age. The code examples use java.util.Vector — and I hope kids today don’t even know what that is. But its lessons still seem necessary. Plenty of people tell me that refactoring is still not as well understood in the industry as it ought to be, and even if it were, with so many new people coming into the industry all the time, we need to show them to use this technique.

I know one of the big changes you made to the book was the addition of JavaScript examples. Why did you think that was necessary?
When I choose a programming language for a book, my first priority is to pick something that the reader will understand. So I need a popular language, at least in the sense that readers can understand it (even if they don’t work with it day to day). Looking at current popularity, that argued for either Java or JavaScript. I went for the latter, partly because of slightly greater familiarity, but also because JavaScript makes it easier to talk about refactorings outside of a purely object-oriented context.

Are there any other major changes to the second edition?
In essence there’s no change. The core technique of refactoring is the same as it was before. In detail, I rewrote almost every page, partly due to the change in example language, more due to a text that’s less centered on object-orientation. You can find more details on the changes [here]. Many refactorings were renamed or generalized. Extract Method became Extract Function, for instance, and I added 15 new refactorings.

Refactoring has been around for a while now, so why is this topic is still relevant?
As long as we still need to write code, we need to evolve it. Refactoring is a foundation technique for evolving our code, ensuring we can continue to easily add new features to an existing code base. We’ve learned that it’s very hard to get software designs right at the beginning. And even when we can, customers’ needs change, and we have to evolve the software in ways we could not predict. Refactoring is a core technique to support this kind of evolution.

Since you wrote the first edition of your book, since then we have seen new software methodologies arise like Agile, DevOps and CI/CD, how does refactoring help developers with these approaches?
Refactoring plays a central role in Agile thinking. Refactoring was one of the original practices of Extreme Programming, which was one of the foundation stones of Agile software development. One of the biggest issues the Agile software community faces today is lack of attention to technical practices. In order to gain the benefits of Agile approaches, you need to know how to change the code effectively as you better understand your domain and the needs of your users. This demands a different way of thinking about architecture and design, where refactoring plays a central role.

Are there any major challenges or areas you see trip developers up when refactoring? If so, how can they successfully move past them?
On a technical level, the biggest challenge seems to be that developers struggle to realize that the key to effective refactoring is taking small steps. A phrase I like to use is “each refactoring is too small to be worth doing”  — but you can make big changes by composing lots of little steps. When refactoring you’re making lots of little changes, and the code works just the same after each change, which makes refactoring less stressful and easy to interrupt.

On a larger scale the biggest challenge is getting people to describe the value of refactoring in economic terms rather than just making the code “look clean.” I often hear people say they can’t refactor because their customers or management want them to go fast, but the whole point of refactoring is that it’s a foundation for rapid delivery. Without refactoring the code steadily deteriorates, slowing down everyone’s productivity. Refactoring attenuates that decline, and done well, reverses it.

Are there any tools or approaches necessary for successful refactoring initiatives?
The most important tools for refactoring are self-testing code and continuous integration. Self-testing code allows me to spot errors quickly, so I don’t introduce defects while I’m refactoring. Continuous integration allows everyone on a team to collaborate effectively while doing refactoring, removing the problems of complicated merges of refactored code.

In addition to these process points, there are tools that will automate refactorings. They have long been a central feature of IDEs such as IntelliJ and Eclipse. The support varies from language to language (Java’s tool support is particularly good).

What do you hope readers will gain from your book?
My primary readers are those unfamiliar with refactoring, often junior developers who have only entered the profession recently. They should gain an appreciation of how to do refactoring and find the example refactorings useful ones to follow in their day to day work. The book grew out of my notes that I kept to remind me how to do refactorings, and I still use them that way for refactorings I do less often.

There’s also an important secondary audience: those familiar with refactoring who need to teach it to others. Here I hope the book will help them pass on this important skill. Often they can say certain refactorings need to be done, and point people to the section in the book for details on how to do it.