Join Simon Allardice for an in-depth discussion in this video What refactoring is not, part of Foundations of Programming: Refactoring Code.
- View Offline
Just as important, as you start to get a sense of what refactoring is, is that you stay very aware of what refactoring is not. And it's easy to get the wrong ideas because we're saying things like we're improving code. And that could imply all sorts of possible meanings. So, three things that refactoring is not. One, refactoring is not debugging. Your code already needs to work. Either on the small scale, you have some classes and methods that are already functional, testable and working. Or on the large scale you have an entire shipped application that's already in use.
But refactoring is not a method for a bug hunt. It's not a way to find either large showstopper bugs, you should have fixed those as soon as they happened. But nor is it a way to find those pesky now you see em, now you don't heisenberg that turn up from time to time. There are ways to find these. There are ways to find these. There are profilers, debuggers, test suites, refactoring is not one of those ways. So if you're ever tempted to think, oh, I'll use refactoring to find and fix those deep difficult bugs. Well, no, you won't because none of these techniques fix bugs. They all assume your code already works.
Now it's true, during the process of refactoring you may notice something that you realize is a problem. But the moment that you start to deal with that. You have stopped refactoring and you have started bug fixing which is a very different mindset. Number two. Refactoring is not performance. This is another very common misconception. That we do this to improve our code. We're cleaning our code up and that's going to make it faster. No, code performance is not the goal of refactoring nor, let me be quite clear here, is it even an expectation.
Refactoring might even make your code technically slower because we're making decisions about the construction of code, unlike building construction. The decisions you would make to build a house as well as possible are not the same as the decisions you would make to build a house as fast as possible. Improving pure performance is something we do in software development but that is a separate process with a different set of questions and a different set of tools. But there is one thing that gets faster with refactoring, us, we do, programmers.
We'll be able to read and understand it, not just individual pieces of code but the bigger application and that can lead to many benefits. Well re-factored code will make us faster. It is not intended to make the code faster. And finally, number three, refactoring is not adding features. If during this process you add a new feature, you support and you use case, you add a single tiny menu item to an application, you are no longer refactoring. Because in refactoring we do not change the behavior of the code.
Okay, behavior. Another hazy, nebulous word in programming. So let's add another word to make this clearer. In refactoring we do not change the observable behavior of the code. We might be doing a lot internally, creating new classes, moving functionality from one place to another, renaming, reorganizing. But the end result of us doing the most perfect, most painstaking refactoring process is that any end user who was using our application beforehand would have no idea we did anything at all. We did not fix bugs, we did not make it faster, we did not add features. We didn't change the observable behavior of the code. So why do it at all? Well, let's talk about that next.
- What is refactoring?
- Recognizing common code smells
- Simplifying method calls
- Making conditions easier to read
- Using refactorings at the method, class, and application level