Code Refactoring: Basic Aspects
Code refactoring, in succinct terms, is the cleanse of the code discarding command lines that are no longer useful … And that’s it?, There’s no more to it? Well, if it’d be that simple, I would not mind a post on this blog.
When refactoring, we reorganize a code, changing its internal behavior without modifying its results. And this topic connects very well with Unit Testing and Test Driven Development, since it is the cornerstone of these two methodologies. The developers perform refactoring in our code in an almost intuitive way without even realizing it and without knowing that it is a way to make code maintenance and make it more readable.
In short, refactoring has four goals that roughly explain the end of this practice:
- Improve the ease of understanding the code.
- Remove dead code.
- Facilitate maintenance in the future.
- Change its structure and design without modifying its result.
Refactoring is cleaning the code…
… but it’s not just that. It looks better when we do this, for example:
- A change of a variable name for something more understandable
- hen we remove duplicate code
- -when we remove the wrong documentation
- In any of those scenarios, we are refactoring.
Refactoring is not Rewriting code…
… it’s similar, but it’s not the same. When we rewrite code, we rethink the original idea by changing even the final objectives. The goal of refactoring is not to change external behavior. If a function generates canned tomatoes, it will continue to generate canned tomatoes.
It is a continuous process without being a specific task…
… is a process that must be a habit to the developer. It does not matter if when you did the function, you made use of arcane magic to make it work. Your principles as a good programmer should dictate that you do a review and, if possible, do a refactor. As a team, you should not make the decision to take a whole sprint dedicated to refactoring code because that would be a waste of time. It is better to do it gradually when completing each task and before delivering it.
Refactoring does not add or remove functionalities…
… because it does not add code, instead it eliminates useless code. It does not add or remove functionalities that increase project productivity, but it does remove those that are not in use or have no goal within the code.
Mathematical Origin
Remember when in subjects like physics or mathematics you did a process in which you had a polynomial and you had to convert it to a more atomic expression? By instance:
(X-1) * (X+1)
Synthesizing results in:
(X² — 1)
Well, refactoring does exactly the same thing. When we write our program, we usually use very long and inefficient sentences to give the expected result. However, in refactoring we make the code more “elegant” and efficient, shortening the procedure and even changing its internal design.
Post Debugging:
When performing refactoring, we verify that the procedure and the internal process of the program is better and more readable. But this connects perfectly with the unit tests in which refactoring comes in when we want to reorganize our code, because a test was not successful or when the code will be tested. In both cases, the internal behavior will change, but not always the external one. Sometimes , it also happens that when collaborating in the projects and / or programs of other people, we find inconsistencies in them. Refactoring can change things to an experience of more order.
It can also be taken as cleaning the code because many times when are re-reading a class, for example, we find lines of dead or commented code that will no longer have any validity. For cases in which code statements change, as in the change from Python 2 to 3 or C # .net 2.0 to 3.5, some statements change in the language. However, both continue to coexist in higher versions with the recommendation to be modified in the future.
…
For inquiries about our development and design services, e-mail us at hola@turpialdev.com.
You can also visit us on the web: turpialdev.com or instagram, linkedin, facebook, twitter
