Refactoring
The art of changing an implementation without changing how it behaves
We’ve finally come to a moment where you finished implementing something and completed all the test given for that implementation to make sure that your software is working perfectly as intended. Now what?
What is refactoring anyway?
According to Martin Fowler from Refactoring.com, Refactoring is a technique to restructure an existing code, altering its structure on the inside without changing how it behaves on the outside. We use this technique to “clean” or improve the code that we’ve made without changing its behavior. For example, you made a lot of similar classes on your code. By making a superclass for those classes to extend, you’re already refactoring your code. There are a lot more example such as removing unnecessary codes, changing design patterns, etc.
Why should I Refactor my code?
There are a lot of benefits that you’ll get by refactoring, since refactoring is part of implementing Clean Code.
- Cleaner Code
As mentioned before, by refactoring your code, your code will become cleaner and easier to understand. Cleaning up the mess in your code before it gets worse as you add more features to your software. A cleaner code will also help your teammates understand your code easier which can fasten your development velocity. - Improve your application performance
An application that is free from unnecessary classes, functions, or any other mess will run faster and smoother. Your software would response quicker and would lead to a better user experience. - Saves time
If you keep refactoring and make sure to keep your code clean as you add new lines of code to your software, it would take less time for you to understand and implement those new codes. This is due to your clean and clear code that you refactor constantly. This way you don’t need to spend that much time trying to understand that code you’ve write months or even years ago. - Easier Debugging
Bugs are annoying to deal with, especially on a source code with thousands of lines of code. With a code that is easy to understand, it would be easier for you to find and debug the bugs on your software.
When do I need to refactor?
Now that you know why should you refactor, when do you need to do it. It is considerably good for you to refactor before you add updates or new features to your existing code. It is easier to build on your code in the future if you go back and clean up your code before adding anything new. Just after delivering your software to public is also a good time to refactor. You are likely to have more free time to refactor at this time and it would help the updates that you will make in the future.
When you don’t need to refactor
It is pretty often that when you create an implementation of something, it turns out that it is not good enough or it doesn’t meet the requirements of your client. So the software needs to be redesigned completely. This way, it is better to just start from scratch rather than refactor as it would be more efficient for you to do.
It is also common to skip refactoring if you are in a tight deadline. Forcing yourself to refactor on a short time frame might lead to frustration as you need to do additional coding and testing. This could be why a certain software may contain bugs after each release 👀.
How my team refactor in our project
On our project, we refactor our codes as part of the development process “Test Driven Development” or in short, TDD. In TDD, our commits are divided into three phases, Red, Green, and Refactor. On the refactor phase, we did exactly what I’ve wrote above. We refactor before adding new features, making sure the code is clean, without changing its behavior.
In the picture above, I changed the Vue.js API reference I was using (Options API to Composition API). Though code has changed quite a lot, the behavior of the software stays the same. The changes that I made was intended to have a cleaner code and to keep up to date with the latest API.
How refactoring affects our project
Since we are working as a team, consistency between codes is recommended. Some of the features that are created by different people might have similar objects or functions. After pushing those features, we tried refactoring so that those similar objects or functions can be created just once and can be imported by the one that needs them. By doing this, our source code becomes cleaner and easier to understand. It is also easier to find bugs in our code as it is easier to understand them.
I guess that’s all I can tell you about Refactoring and how my team use it on our project. I hope that this article can encourage you to refactor your codes to have a better development process.
References:
