What is refactoring?
Refactoring is the process of improving the design of existing code or, in human language, it is the process of getting more readable and less complex code. The crucial point is that code is changing without losing functionality.
Why developers need refactoring?
It is used to make code simpler, more compact, and clearer. A slim, well-structured code is easy to read and quick to refine. But frankly speaking, it is almost impossible to make code perfect at the beginning. Requirements may change, customers come up with new bells and whistles, testers find bugs that need to be fixed quickly, developers nervous.
The quickest way to fix/implement something is not always the best, so developers may use the quickest approach like copy/paste. That’s how the spaghetti code comes about.
What benefits we can get from it?
A regular and accurate process of code improvement can lead to:
- maintaining the clear architecture of the project,
- simplifying the future life of developers,
- making code understandable and transparent for all team members,
- speeding up development and error hunting,
- updating out-of-date parts of the code,
- reducing bug finding time.
So, with routine code cleaning, we don’t get stuck in a rut.
When is refactoring a real necessity?
Despite the great goals, it is not always required to refactor the code. Sometimes it means shoot yourself in your foot. Well, let’s look at the main reasons for using refactoring and cases when we don’t touch the code.
Dead code
A variable, parameter, method, or class is no longer used: the requirements for the program have changed, but the code has not been cleaned up. Such elements or sections of text should be removed.
Duplication
The same code performs the same action in several places in the program. Put this part in a separate function.
Incorrect names
Names should describe why this element exists and how it is used. If you see that the programmer’s intentions are unclear without a comment, refactor it.
Too long functions and methods
The optimal size of these elements is 20–30 lines. Divide the function into several small ones and add one general one.
Too long classes
Same thing. The optimal length of a class is 20–30 lines. Split the long class into several smaller ones and include their objects in one general class.
Lots of comments
Bad code is often covered with a lot of comments. If you feel the urge to explain some code fragment, try to rewrite it first to make it clear. Useless comments clutter up the program, and outdated and irrelevant ones are misleading.
Chains of messages: non-compliance with Demeter’s law
It says that any method of any object can only call methods from:
- its object;
- parameters transferred to it;
- any object it has created;
- autonomous objects with direct access.
A software module must interact only with the module’s “friends” known to it and not with “strangers”.
Using statics
If you apply statics, you must be prepared for the code to become unpredictable. The data is not encapsulated in objects.
What profits will you get in these cases?
Code improvement is a good way to speed up dev’s work in the future. So, understandable and well-structured code can be refined with minimal loss of time. But successful cases are the tip of the iceberg. Consider the other side of the coin.
What are the dangers of refactoring?
If the code is basically crippled, no witchcraft will help it. Then, it is easier to rewrite it. But if we are dealing with good but slightly dirty code, it is worth looking at possible consequences of the improvement process:
- Careless refactoring can set back a project from release for weeks.
- Imprudent refactoring can break the functionality of the program.
- The number of bugs may increase.
Even though refactoring doesn’t affect the functionality, we are still working with code.
When is refactoring useless?
Sometimes the desire to constantly fix the code becomes stronger than the desire to continue writing the new one. This is the first danger.
Manifestation of perfectionism
The code works, the client and users are happy. So don`t touch the holy cow.
Refactoring instead of adding features
Sometimes the developer can stomp around, making the code aesthetic. But code itself is neither a goal nor a value. It is written for usability, functionality improvement, etc. So if your code works right — implement the following features.
Refactoring without aim understanding
Arm yourself with code understanding and business logic. Then do refactoring.
How to refactor correctly?
It’s a good idea to create a backlog of tasks with the identified problems of the project, and do sprints to close them from time to time.
Refactoring must be listed in the dev’s work plan and must be quantified. Task — goal — period of doing. This will prevent all from getting lost in hours and tasks.
We need to train critical thinking and prioritization skills. You need to understand why you are refactoring and whether it is needed at all.
Future of refactoring
Trends of code improving tools are:
- accessibility,
- clarity,
- fees-free.
By far the most promising topic for code manipulation is VSCode. It can apply:
- Extract Method
- Extract Variable
- Rename symbol
- Key bindings for Code Actions
However, for native development, for example, for IOS, it is cooler to do refactoring with the help of XCode. Tell us what tools you use and how often do you refactor?
