Code Refactoring
This article talks about refactoring and why we should refactor our code.
Actually, this article can be a continuation of my latest article (the article before this). Now you might have a slight idea of what is the purpose of code refactoring. Yes, it’s to achieve ✨ clean code ✨. Why is it so important, though?
Say you’re developing a (long-term care) software with your team. It can be exhausting and frustrating (even) just to think about the continuous demand for new features and bug fixing. Refactoring can help you with that.
So, what is refactoring?
Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.
— Martin Fowler
The main purpose of refactoring is to tidy up the mess in your code. Writing your code correctly that results in successful functionality may give you some (temporary) satisfaction. But, writing your code correctly, structured, and cleanly, may give you even more satisfaction and happiness. 🌻
We know that it is called a software for reason, right? Updates, costs, security risks, compatibility issues… you name it. Fixing bugs and adding new features might lead to unnecessary complexity and technical debts, which can slow down the development team.
How do we know when to refactor? Our refactoring guru has the answer. 😎
When you’re doing something similar several times, it’s best to start refactoring. It is also best to refactor when adding a feature and fixing a bug so that you can have fewer debts in the future and your team can iterate faster and further. The code review may be the last chance to tidy up the code before it becomes available to the public.
How to refactor
Refactoring isn’t (or, shouldn’t be) a special task that would show up in a project plan. It should be a regular task that you do when you’re developing your software. In my opinion, it isn’t even a stressful task, it’s more like a “do-it-for-healing” task, and it makes me happier. 😄
You may refactor your code when you found that your code has code smells, bulky structure, duplications, and other things that you consider “dirt”. When you feel like you’re struggling with your code, consider refactoring it to a better shape. When you feel like it’s clean and clear enough, then you’re good to go. 🚀
If you’re using a quality gate tool such as SonarQube, it may be easier to refactor, since it tells you straightforwardly about the code smells, duplications, vulnerabilities, etc. For example, this:
It’s easier to detect code smells with SonarQube as it tells you the exact location of the smell. If I select the fifth code smell (at the second from the bottom), it will tell you the source of the smell. xD
Now that I know the exact location, I can directly refactor that by defining a constant like this:
HIBAHLIST_VIEWNAME = 'infohibah:hibah_list'Or any other possible way that’s better.
If all of the code smells are fixed, the interface will look like the image above. No code smell! 😆
If I consider that as a false positive, I can resolve that too.
Having a tool like SonarQube is nice and helpful, but not necessary. Taking small steps and testing frequently will do your refactoring job as well.
I’d say, refactoring is worth the time. 👌