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.”
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.
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.
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.
Please log in again. The login page will open in a new window. After logging in you can close it and return to this page.