In the developer community, there is often talk about refactoring. What exactly is this process? Why does it need to be done? And why do they pay so much attention to it? Let’s look into this article. Let’s take a cafe as an example
Let’s imagine that we opened our own cafe, equipped it with an excellent kitchen and hired an experienced chef. To begin with, we have included only the simplest dishes in the menu so that they can be heated in the microwave. Next to the microwave, we put a rack for the necessary utensils.
A couple of months later, as things were going up, we added flour products to the menu. We bought an oven and installed a tray rack next to it. Free space in the kitchen has become less, the chef has to bypass the rack and constantly stepping over the wires, but in general, the work is not interfered.
Some time later put a fryer with a mixer for kneading dough. There were more wires. Another cabinet appeared next door. A second cook was added to the staff. As a result, the kitchen became chaotic: a clutter of furniture and equipment, moving around and cooking food became very uncomfortable. If we decide to install a new stove, the situation will get much worse, because there is a catastrophic lack of space, although it would seem that the area allows everything to be placed.
Then there is a kitchen planner, who creates the design anew and arranges all the tables, cabinets and devices in their places. Now the kitchen has a completely different environment: The equipment does not interfere with the cooks’ work, the wires are neatly hidden in boxes, and counters do not block the aisle.
At the same time, nothing has changed for visitors: we have optimized only the kitchen – everything on the menu remains the same. This is what is called refactoring – when changes are made only to the interior, and although you can’t see it from the outside, the further work becomes much easier.
In development, code refactoring means modification of code which does not affect its functionality but improves its readability and facilitates further maintenance.
When you need refactoring in programming
There are two types of refactoring: planned and necessary.
Refactoring which is initially put into the development cycle by programmers is called planned refactoring. For example, it may be scheduled every 6 months or every 4 splits.
In large companies, which usually have a lot of legacy code, separate teams are formed to deal exclusively with refactoring old stuff. This makes it easier and faster for the other teams to understand what is going on in this code and how to use it.
The second variant is refactoring when it is necessary. This is resorted to when it is difficult to add new features into the old code. Then we pause the process and allot some time to rearrange what was there.
Important points to consider when refactoring
How can we tell if the refactoring was successful or not? Yes, if it resulted in making the code cleaner, simpler and clearer.
For instance, if variable A is responsible for the number of customers, it is advisable to call it customerCount – it will make the code easier to understand.
If the fragment is used several times, it should be implemented as a separate function/method. This way it will be easier to make changes in the future – to update one place, instead of searching for the same fragments on all lines.
For better code readability, large functions that do not fit wholly on the screen are divided into several smaller ones. Sometimes, some of the functions are moved to a separate file and then appended to the code.
You should understand that refactoring is not a synonym for optimization. Its aim is to make the code clearer, while optimization is needed to make the program faster and more efficient.
Can we do without refactoring?
Of course, refactoring is not necessary. But the longer you avoid it, the harder it will be to work. It’s like cleaning your workplace: the longer you leave it untidy, the more uncomfortable it becomes. Regular refactoring saves you from slowdowns in further development and thus makes life of large teams easier. Only small and slowly developing products can do without it.
Add comment