Refactoring: What If a Book Taught How to Improve Existing Code? 

 September 4, 2011

by Jon Reid


Book cover: Refactoring

What would you give to be able to improve your existing codebase with complete safety?

Disclosure: The book links below are affiliate links. If you buy anything, I earn a commission, at no extra cost to you.

The Refactoring book completely changed the way I code.

In 2001 while searching for information on design patterns, I discovered the original wiki and stumbled onto Extreme Programming. This led me to a software development conference in 2002 called SD West. There I attended a session by Martin Fowler, and knew that I had to pick up his Refactoring book that day.

How could I resist a book that promised to teach me about “improving the design of existing code”?

Refactoring: Co-opted in the Workplace?

Many years later, I find the term “refactoring” being thrown around in the workplace, at company after company. Programmers and managers often talk about “refactoring,” when they mean “rewriting.” I’ve seen nightmares brought about by so-called “refactoring” that introduced so many defects, it compromised the product ship date.

Programmers talk about "refactoring," but they usually just mean "rewriting."

Click to Tweet

The Refactoring book, however, teaches a disciplined methodology of changing code in small steps, with automated verification of each step.

Of the books I have at work, I keep just a few within easy reach for looking things up. This is of those books. Each refactoring has a detailed recipe of its steps. Things usually go better when I open the book to follow those precise steps.

If my statement that it “completely changed the way I code” seems like hyperbole, another blogger states it even more strongly: “That moment changed my life.

Would you like to transform ugly code to make it better, but do so safely? What are you waiting for… buy a copy of the Refactoring book today!

Update: What About in 2022?

Xcode has a “Refactoring” menu. Do we still need this book?

To answer this question, go look at the catalog of refactorings. Compare this list to what you see in Xcode. …No, it doesn’t come close.

For Swift, even AppCode pales in comparison to the support IntelliJ has for automated changes to Kotlin or Java. (AppCode does have a more robust choice for Objective-C.)

No, those of us who code for Apple environments must often lean on the steps listed for each refactoring in the book. (Or, just stab about wildly and hope things work eventually.) How do you move a function in Swift from one type to another, with zero “now I’ll fix it” time from the code not compiling? By following the simple steps in the book.

Other Resources:

Question: How is refactoring perceived at your company? Leave a comment below.

Jon Reid

About the author

Programming was fun when I was a kid. But working in Silicon Valley, I saw poor code lead to fear, with real human costs. Looking for ways to make my life better, I learned about Extreme Programming, including unit testing, test-driven development (TDD), and refactoring. Programming became fun again! I've now been doing TDD in Apple environments for 20 years. I'm committed to software crafting as a discipline, hoping we can all reach greater effectiveness and joy. Now a coach with Industrial Logic!

  • Hi,
    Finally received my copy of Refactoring. The hardcover somehow reminds me of the time I was in college.
    Enjoy the rest of the weekend.

  • {"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}