Balancing Reusability in Software Development?
Let us start by assuming a situation of a frontend developer who recently switched to a big organization. He got a task to build the user interface for a new referral program with the cool Figma design. Even with his experience of 5 years, the first question that came to his mind was “does this component already exist?, what about this icon? Maybe this exists”. An extrovert developer will quickly consider this as a chance to ice-break with their colleagues whereas an introvert developer will start analyzing the huge codebase and start with the most efficient searching algorithm to find the required pieces.
This whole process seems so natural, what else can we do? We can’t reinvent the wheel. Moreover to it, Will the code look good if we have duplicate things?
We can see that there is a problem with the process of reusability we are following but before that, we first understand the advantages of reusability.
Reusability, as a principle
Reusability is one of the first coding principles that every software developer learns. Because it helps us in many ways. The following points summarise the advantages of reusability,
- Saves effort, energy, and time: It saves our effort in writing the same piece of code and testing it again.
- Reduces the size of the codebase: It helps in reducing the size of the codebase as well as the method count.
- Modularity: Reusable business logic can also lead to more modular code.
- Core Configuration: One of the biggest applications of reusability is core configuration like base URL, application theme, etc. which needs a single point of control.
Also, there is a well-defined principle that says “Don’t repeat yourself” to advocate reusability.
But this principle states “Don’t repeat yourself” but what about “Don’t repeat others”.
Don’t repeat others
The major issue with reusability is to find something which can be reused. If code is not written by you then it is very difficult to find out if something already exists. If the team size is very large then it is sometimes become impossible to find the code that you need.
What can be reused?
Consider you got a chance to start a project from scratch. You decided on the architecture and guidelines for your project. In the process, you also created many reusable components. After some time you decided to move on from the organization and as time passes, some more left, and some new developers joined. What are the odds the same components will be reused?
Well, it depends. But depends on what?
- Complexity: If the component is complex enough to write again (or hard to find on StackOverFlow) then there are better odds for reusability.
- Popularity: If the component is used very frequently in the codebase. There is a very high probability that it will catch the eyes of the developers and can be reused again.
- Application: If you are working on a SaaS application then the chances of reusability increase, contrary to it if you are working on consumer-facing application chances of reusability decreases.
How to write reusable components? Visible reusability
You must be conscious enough while writing a code. First, make code reusable for yourself. If you want your code to be reused by others then think of it as 3rd party library which helps others in solving complex use cases. Write proper documentation, make code modular, let everybody know in your team about the code, and make it visible.
How to use reusable components? Conscious reusability
One thing to keep in mind while using code written by someone else is the intention. Sometimes you will find the code that can be used for your use case but the intention of the code can be different. E.g. a utility class that will give you a countdown timer but if you want to create a stopwatch you should not use the countdown timer.
What is wrong with re-using a countdown timer? The problem is you have to modify the countdown timer to make it work as a stopwatch. And modifying the existing timer is a bad idea because if the timer is already used at different places then you might increase the chances of breaking a stable code.
Either figure out the underlining layer that can be re-used for building a stopwatch or figure out a way to extend the code without impacting the older code.
Conclusion
Software development has changed a lot in the last decade. The industry shifted from SaaS products and productivity software to Consumer-facing products where business use cases and UI can change frequently.
Find patterns according to your application, and where you need control, and where you can give freedom to developers must be thought through. One good example for larger teams could be modularization, where a small team can have the freedom to work in their modules and can reuse the other modules but any multi-module change will either require proper process or good linting checks or both.
Reusability is indeed a very important principle to learn which leads to modularity and less coupling of code. But when overused or used unconsciously, it can bite us back.
Please post your thoughts in the comments; If you like it please give it a few claps.
