Refactoring and its Implementation in ReactJS
Refactoring is one of the necessary stages in software development. If you had experienced using the test-driven development (TDD) approach for developing your software, you might notice that it has its own refactoring phase after the green phase. Even if you are not using the TDD approach (although you should), you may still refactor your own code consciously with some refactoring knowledge or unconsciously using your “feelings” on what is right. I hope by reading this article, you can make yourself consciously refactoring by using the knowledge.
To learn more about refactoring, we have to learn about the term technical debt first. It is the main problem and purpose of why we need to refactor our code.
Technical Debt
Technical debt, also known as design debt or code debt, is a phrase originally coined by Ward Cunningham. He made an analogy of technical debt with the financial debt concept to explain the problem with nontechnical stakeholders at that time.
If you get a loan from a bank, this allows you to make purchases faster. You pay extra for expediting the process — you don’t just pay off the principal, but also the additional interest on the loan. Needless to say, you can even rack up so much interest that the amount of interest exceeds your total income, making full repayment impossible.
— Refactoring Guru on Ward Cunningham’s metaphor
Technical debt is any code that costs the agility of the overall code, making the code harder to be maintained in future development. The same as financial debt, it makes you achieve the goal faster at the cost of agility, just like taking a loan.
Business Pressure
Sometimes, there are business circumstances that force developers to release features with “uglier” implementation of the code, prioritizing delivery deadline over a better design implementation. Developers may take a “shortcut” to deliver it.
“Well, I just need to get this done quick to meet the deadline. I’ll come back to fix it later.”
— Programmers
Not a mess
Technical debt is NOT a mess. Technical debt is based on a logical decision over the project, not an irrational one. A mess is always based on unprofessionalism and lack of knowledge of writing code. It may be appropriate to have technical debt, but it also had better be clean! Even though the code is dirty with technical debt, it is made because of a logical reason, not because of the laziness of the programmer.
For example, you have to decide whether to choose solution A or B to tackle a problem. A is faster to implement but bad for future design and B is future-proof but it takes time to implement and you have a tight deadline. Even though you chose solution A, you have to make sure that the workmanship of the solution is top-notch. Otherwise, the messy code will make you confused and you will get a hard time changing the implementation to solution B later on in the future.
Neutral
Technical debt is not necessarily bad. Just like debt in financial analogy, it is a tool, a risky one. It becomes a bad thing if you never pay the debt.
Refactor
“Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.”
— Martin Fowler on his website
Refactoring is changing the implementation of your code without editing the feature behavior itself. It is a behind-the-stage activity. It improves the application, but it is not observable to the users.
Refactoring is done to pay off the application’s technical debt explained above. Refactoring sometimes is also done to fix messy code. Refactoring makes the application become more agile, more flexible, and easier to be maintained by developers.
Criteria of a success refactor
- The code should become cleaner or better.
- There should be no new functionality.
- It should pass all existing tests.
Martin Fowler’s website and Refactoring Guru have a full list of refactoring techniques. I also made an article about clean code that may support refactoring knowledge. In this article, I am just going to explain a few of them, not all the techniques mentioned on those websites.
Refactoring in ReactJS
My friends and I are currently working on an application called Sistem Informasi Penilaian & Database Praktikum. It is an information system application for a faculty at my university. This application is mainly made using ReactJS and Django. This application was already developed by my seniors and my team has a job to develop it further and that’s why a lot of refactoring was needed. I would like to use this application as an example.
Renaming props, methods, and components
The first refactoring technique that I used is renaming things. On the first image, I renamed auth and admin to isAuthenticated and isAdmin to make the variable datatype clearer.
I changed the method’s name in the second image because the previous name is not correct (not representing the purpose of the method). The same applied for the third image.
Using functional components over class components
By version 18.6 of React, it is better to use a functional component than a class component. Using the same example as above, I changed the implementation of the code. I also deleted the async because I do not need anymore.
Removing dead code
In my application, dead code was everywhere! There were several short and long commented codes. There were also unused components and codes. I deleted it all.
Remove unnecessary props
Unnecessary or unused props are one of the things that have to be refactored. This thing is too easy to be forgotten. Make sure to delete these!
Making things DRY
DRY means Don’t Repeat Yourself. One of the technical debt that was inherited by previous developers is duplicate codes. I refactored the application by removing duplicate codes and ensuring that the code can be used by many other interfaces.
Extracting Components
Extracting components is often used in React. Using the three rules, we can remove duplicate codes and also keep the code short in each file.
Rule of Three
- When you’re doing something for the first time, just get it done.
- When you’re doing something similar for the second time, cringe at having to repeat but do the same thing anyway.
- When you’re doing something for the third time, start refactoring.
Closing Statements
Well, this is refactoring. It is a very important stage in software development. It saves developers from nightmares in the future, especially in developing applications with large features. So be sure to pay your (technical) debt!
This article is only an entry point for you to learn about refactoring. There are still lots of things to learn. You can find other articles on the internet or read books like the Refactoring book by Martin Fowler.
I think that is all from me. Any corrections or comments are highly appreciated.
Thank you!
