Quality Coding

Refactoring Demo: Is It More than Just Changing Stuff?


Refactoring. It’s a word I hear quite a bit. Usually, in the context of conversations with management, it means, “Rewriting that thing. Hopefully without introducing bugs.” Often, among developers, it means, “One of the options in the Refactoring menu in my IDE.”

Inigo Montoya meme: "Refactoring, you keep using that word. I do not think it means what you think it means."

Tools vs. discipline

A tool is not the same thing as a discipline. For example, Jenkins is not Continuous Integration. And just because you’re using Jenkins doesn’t mean you’re practicing CI. You may only be doing “CI Theatre“.

I’m afraid the same is true of refactoring. Just because you use a menu item doesn’t mean you’re refactoring. You may only be doing Refactoring Theatre.

Refactoring demo screencast

So here’s a refactoring demo in a 12-minute screencast. In my TDD sample app, I want to move a line of code into a class which doesn’t yet exist. Whenever I run unit tests, I call it out with a “ding” sound effect, and a text overlay in the upper-right corner. Watch how many times I run my unit tests, and how often.

I hope my use of AppCode, and calling out the shortcuts I use, doesn’t detract from my message. I’m a big believer in having good tools and using them well. For me, that means I prefer AppCode, which is a keyboard-centric IDE. Despite the shortcuts I use in Xcode, it remains largely mouse-centric.

My goal in this screencast is to pretend that we’re pair programming. That way you can see not just the end result, but the steps I take, and how.

Do you have the Refactoring book?

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. Don’t delay: Buy yourself a copy today!
Have you seen this kind of refactoring in your workplace? Please share your experiences in the comments below.

About the Author Jon Reid

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 Design Patterns, Refactoring, and Test-Driven Development (TDD). Programming became fun again! I've now been doing TDD in Apple environments for 18 years. I'm committed to software crafting as a discipline, hoping we can all reach greater effectiveness and joy.

follow me on:
  • Alan says:

    Nice post, Jon!

  • Raymond Law says:

    You hammered it home.

    I dislike Xcode’s Refactor menu item. Rename isn’t really refactoring. Extract is just moving code to another function. Those are so low-level. A much higher level thinking is required to architect an app properly, and refactor to improve code.

    • Jon Reid says:

      But Rename Method and Extract Class are important refactorings. What I’m trying to show is the importance of small steps verified by unit tests. The goal is to minimize time “in red”.

  • Vui Nguyen says:

    Wow, this is like “iterative refactoring”, which is a term I just made up :) I like the idea of refactoring so that the code still works every step of the way, instead of leaving things broken until the end. Thanks for the screencast and post, Jon! This was valuable for me.

    • Jon Reid says:

      Glad you liked it, Vui. It’s unfortunate that the term “refactoring” has been so corrupted. So… welcome to “iterative refactoring”!

  • >