Refactoring code is a crucial skill for every software developer. Martin Fowler's Refactoring: Improving the Design of Existing Code is the classic text on refactoring. This article is a brief summary of the book which explores what refactoring is, why you should do it and how it can help you towards a better understanding of your codebase.
What is Refactoring?
Refactoring is the process of improving the design of the code after you wrote it. During refactoring, you are changing the internal structure, without affecting its functionality.
Here is the dictionary definition of the word 'Refactoring', both as a noun and a verb.
Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.
Refactoring (verb): to restructure software by applying a series of refactorings without changing its observable behavior.
Why Refactor?
Software design doesn't happen at the beginning. It occurs continuously during development. As you develop, your understanding of the code improves. You find better ways to structure your code that improve the design.
A poorly designed software program is hard to change. First, it is difficult to figure out what to change in the first place. How these changes will interact with the existing code is another problem. There is a good chance of introducing new bugs when you are modifying code.
When you have to add a feature to a program but the code is not structured conveniently, first refactor the program to make it easy to understand and to add the feature, then add the feature. - Kent Beck
In refactoring, you make small changes to the code and test after each change. This transforms complicated code into well-structured code over time. Each refactoring change is simple. Yet the cumulative effect of these small changes significantly improves the design.
Refactoring makes the codebase easier to understand and reason about. This helps you find bugs and program faster.
Towards Better Understanding
When you are coding, you can have two types of understanding about what the code is doing.
-
Short-term Understanding
- You read code, you understand, but you forget about it a few days later. It is fragile and temporary.
- When you come back to the same code after some time, you have to again make an effort to understand the code.
-
Long-term Understanding
- You persist the first type of understanding by moving it from your head to the codebase itself.
- The code tells you what it's doing. You don't have to figure it out again.
You move from a short-term to long-term understanding in two steps.
First, extract the complicated piece of code into a new function. Then, give it an intention-revealing name. The name should tell you what it's doing.
You can always go to the function definition to see how it's doing it, but you don't have to. You abstract that code to something simpler. The next time you are reading the code, a glance at the name tells you what the code is doing.
Read the code, gain some insight, and use refactoring to move that insight from your head back into the code.
The clearer code then makes it easier to understand it. It leads to deeper insight, a rich domain model, and a beneficial positive feedback loop.
There you go. Even if you have read this book before, it's time to read it again. Please read it before writing another line of code.
If you enjoyed reading this post, you might like:
Top comments (0)