Refactoring and rewriting Nexfon: The experience
Preface
You can find problems and bugs in every living software. As we always say, there is no complete code and one must always try to refactor and improve.
Every now and then I’ve come across a software that is working as expected and noticed that not much effort is put into it’s soul to be clean and open for extensions.
So what would you do when there’s a new feature and a change in the code might break the old functionality completely? As Martin Fowler said in Refactoring: Improving the Design of Existing Code
When you find you have to add a feature to a program, and the program’s code is not structured in a convenient way to add the feature, first refactor the program to make it easy to add the feature, then add the feature.
My suggestion tough is, you have to create an alternative universe where you begin refactoring the code and maybe redesigning the architecture of the software. Repeat this process periodically. Who knows what your customer may need in two years or what would change in software engineering world. At least that’s what we’re doing for Nexfon.
And I’ve joined
When I joined the team on October 2019, Nexfon was already facing some new and critical changes. The old design of the online charging system in Prime-Nexfon was failing on scale and the billing system was not so much of an automatic software. The architecture of the Pro-Nexfon was also eating a lot of resources and the maintenance process became like a never ending headache.
Luckily there was a bright and shining road map. That was one of the main reasons I’ve joined the team. Although there is not much left of that team now but I’m happy that all the remaining and new team members can taste the sweetness of doing something meaningful.
My job begun as a member of the team to redesign, rethink and restructure from within. We’ve become Trojan horses in the city of the Nexfon. The road map was fund of micro-services so we’ve become micro-service developers. The road map also had some dark and unknown questions so we’ve become research experts.
The experience
Micro-services, micro-services everywhere.
We’ve decided to smash down our existing software to multiple micro-services. This way we can be worry about smaller problems and fix them easier at a time.
We’ve designed, developed and used new services to handle file uploading and streaming for documents, call recordings and voice mails, a new online charging system and semi-automatic billing management to handle real time rating and also billing. Finally we have separate the logic of these micro-services from the main purpose of the software as we should, so they can live together but be independent! Our micro-services developed to be shy. They do not know much about each other.
We haven’t neglected the open source community in our path and have used the experiences of so many bright engineers from Berlin to Nevada. We communicate with them, ask for their opinions and suggestions. Finally we make decisions with an open mind.
But what about the existing codes? We throw away some parts of it unfortunately. The remaining code must become compatible with the new micro-services, so we adjust and change them. Believe me when I say there was so much cleaning, refactoring and rewriting.
As the result, our codes that handles the calling functionality of the software becomes shorter and cleaner but in the meantime more efficient and scalable.
We design our micro-services to be highly available and use fallback solutions when needed. The idea is when the software is going to break, we break sooner than later. There are multiple processes and threads to handle new requests and we’re not worry if one of them is not available for a short period of time. The architecture makes sure that no call passes without a rate!
What then?
The refactoring process is becoming a state of mind in our team. We intend to improve constantly. This is a never ending path with a never ending goal.
To be better than before and to be more clean and efficient.
Takeaway
- Refactor your code and software constantly in small chunks. In other words refactor early and often.
- Rethink your problems in a new way with a new perspective.
- Think about scaling and high availability beforehand.
- Don’t be afraid of changing someone’s code, they’ll do it if they have the chance.
- Break things sooner than later.
- Don’t be afraid of missing something, there is another refactor coming soon.
