Join Simon Allardice for an in-depth discussion in this video What refactoring is, part of Foundations of Programming: Refactoring Code.
Refactoring is the name we give to a collection of small, independently learnable techniques for improving code that already exists. Meaning this code is already written, and it's already working. We are not changing what it does. Now these individual techniques, each one called a single refactoring are often very small. They can be described in a few minutes. And they each deal with one specific common issue, and the most likely way to, well, fix it, is not the best word because it's not broken. They deal with the most likely way to improve it. Now each of these different techniques has a name. There is the extract method refactoring, the replace array with object refactoring, the remove middleman refactoring and many more. And the idea is that you build a personal library of these techniques, like having a personal programming improvement toolkit.
Different tools for different situations. Tool kit is actually not a bad analogy for this. Like working with tools, there's no particular order to this, no fixed one, then two, then three path for using these refactoring techniques. Just as you wouldn't always use a hammer first, and then a Phillips head screwdriver, and then a quarter inch socket wrench. You just want them all available if you need them. So, it doesn't remove your brain from this process. This is programming, there is no such thing as a set of rules that just anyone can follow to turn bad code into good code.
But it is a set of techniques to help you recognize these issues as long as you bring your consciousness and your experience with you. Refactoring techniques applied without thinking, will hurt more than they help. Just because you have a hammer, doesn't mean everything needs to get hit. So, how many are there? Well depending on what source you take as gospel, and we will talk about that, there are between 75 to 100 or so different well-defined refactorings. But like most things, it is a smaller subset that are the most useful and that's what I'll focus on in a course like this. The 30 or so most general, most useful refactorings.
The equivalent of the hammer, screwdriver and allen wrench tools you always want in your toolkit. Rather than the equivalent of the specialized 1983 RX7 rotary engine pilot bearing remover and engine down pin puller tool. Yes, specialized and rare refactoring techniques do exist, but we want general purpose here. Now if you've been writing code for awhile, you've almost certainly kind of done some of this already. If you've ever looked at a method that was getting a little too long. Found a few lines in it that belong together.
Separated those out into their own method. And then replaced the original code with a call to that new method. Well, that's a refactoring, that is the extract method refactoring. doesn't mean that just because you've done that kind of thing once or twice, you've been doing refactoring all along. Because using the formal refactoring technique, brings more conscious awareness to that decision. It doesn't replace your intuition, but it gives you some more questions to ask. If you're trying to break apart some code, what should you really be looking for in this situation? What do you do when there's a mixture of local and non local variables in the original code? And are there any contra-indications, any reasons why you might not break out some code into its own method? And that's the kind of thing we'll go through for each of these. No single technique is the master refactoring.
It is the cumulative, additive impact of many small changes done consistently that is the real improvement here.
- What is refactoring?
- Recognizing common code smells
- Simplifying method calls
- Making conditions easier to read
- Using refactorings at the method, class, and application level