Any codebase that is old enough will ultimately contain legacy code. The moment architecture, performance, and comments are written, they begin to degrade.
Some parts of the codebase persist longer than others, but new coding standards will undoubtedly arise to eliminate technical debt. Then you have to redesign a major program with no downtime while creating a "new way" of working without compromising your release or development.
One successful solution is to use the Strangler Fig Pattern.
Strangler Fig Pattern derives from a group of plants that "strangle" their hosts as they grow. They thrive in scarce light, and they have evolved to disseminate their seeds (usually by birds) to the top of a host tree, where they may obtain plenty of it.
Their roots develop around the tree, while the seedlings grow upwards to absorb as much sunshine as possible. This "strangles" the tree, and the fig saplings often destroy the host tree on which they landed. What does this mean in terms of software?
Rewriting a huge, complex codebase with many distinct interactions, typically involving multiple teams, is a planning nightmare. Going big-bang (releasing everything at once) on large, complicated brown-field projects like this forces you to:
To top it off, it usually results in a lot of overtime for developers and an onslaught of defects. When we use the Strangler Fig, one of the major challenges we aim to eliminate is making sure that anyone using your program knows where your new software is now available.
If you are rewriting your backend, for example, put everything on a new endpoint and ask your users to point to your new endpoint. However, if something goes wrong, you may have to ask everyone to return to the old one.
If you have tough bugs that are likely to frustrate your consumers, you may switch between these two destinations. We can avoid all of the above by using the Strangler Fig pattern.
The Strangler Fig pattern tries to rewrite small pieces of your codebase incrementally until you have strangled all of your previous codebases. It can be eliminated within a few months/years.
The general flow is as follows: add a new component to your system that has not been used yet, turn on the new part of the code (usually with a feature flag so it coexists with the old code), and remove the old code.
It not only helps you avoid all of the problems we have just described but it also:
The Strangler Fig pattern can be implemented in various ways, depending on the system you are deleting and so on. Let us get specific and look at an example.
Assume you have a large monolithic back-end codebase for handling payments. It is enormous. You wish to rewrite a few million lines of code with various endpoints for various reasons into something fresh for your firm.
The design is too difficult for new developers to understand, and there is a lot of dead code you need to remove but do not want to break anything. Breaking a large codebase requiring client payments could result in the unfortunate developer pushing up last and losing their job!
How do you gradually eliminate this ancient codebase? This is challenging. You don't want to add a new endpoint and compel everyone to transfer simply. If you have faults and need to roll back, you can not merely switch back and forth.
You do not want to alter your interfaces to these endpoints to add one more hurdle. Everything that is supplied as an argument or returned should be identical.
We can build a front end that intercepts requests for legacy endpoints. The new façade will redirect to the new API you created or the legacy API if you have not updated that part of the software.
This facade acts as a shim, catching network requests and routing them to the appropriate destination. You may then gradually migrate to the new API, with your users oblivious of any changes to your underlying code because you have properly abstracted it away.
If you complete it correctly, you should be able to:
The strangling happens in stages as you shift more and more responsibilities away from the legacy API and toward the new API.
I hope this has clarified the Strangler Fig Pattern and some of its advantages. This pattern has been utilized in real software projects and has proven quite effective. It was easily one of the most difficult tasks I have ever worked on, and the Strangler Fig made it a breeze.
It keeps you from spending months writing software projects and then crossing your fingers that you have not forgotten anything before putting it into production.
If you want to learn more about computer code and programming, here’s an article on why algorithms are important.
Main Image: Click here