At WATA Factory, we have been confronted on several occasions with the modernisation of projects with Legacy code. In this article we will talk about how we have approached and how we have handled the situation.
To get into the subject, we have to ask ourselves the following questions: (1) What do we understand by a Legacy project? (2) If it works, why should we change it? (3) How do we do it? Let us see!
What do we understand by a Legacy project?
For us, a Legacy code (or spaghetti code) is a code where, what we consider to be good development practices (clean code), is neither applied nor follows SOLID principles and furthermore has no good (or absolutely no) test coverage.
Usually this code is an old code that has been in use for several years (and is more or less reliable), developed without framework or, in its lack, using an old version of one (e.g. Symfony 2).
If it works, why should we change it?
This is a very good question, especially because in our branch you often (sometimes too often) hear: if it works, don’t change it.
The answer to this question is not easy. We should consider modernisation (or not) from the point of view of sustainability and coherence with the practices that are carried out daily in the company.
- Sustainability, because when we talk about an ongoing project, every time a new development is made, all we achieve is to keep feeding the monster. The time will come when the modernisation we have been talking about will be practically impossible without investing a lot of time and therefore money.
- Coherence, because if the new projects follow a series of quality standards, unity or integration tests, etc., why will we have ongoing projects where these practices are not applied simply because it is a long-term project?
How do we do it?
If we have reached this point, it is because we are convinced that we want to renew our code.
At WATA Factory we work with Symfony, so in our case we will create a project for this framework and integrate the Legacy code in it.
When we develop new features, we will develop them as part of the Symfony project. The old features will be included in what we will call LegacyBundle. We implement this process by following the steps listed in this guide (published by Yannick de Lange).
This bundle will contain the entire Legacy project, and by routing we will redirect our new endpoints to the old code so that everything still works.
This structure allows us to avoid having to migrate the entire project at once, with the time and risk that this entails. When we modify existing functionality, we must remember to remove it from the Legacy area and add it to the new area. This will lead to the Legacy part becoming smaller and smaller over time.
If for some reason Symfony is not used and the Legacy code and the new code cannot coexist, we recommend following the guide included in the book Modernizing Legacy Applications in PHP by Paul M. Jones.
Paul M. provides us with guidelines for modernizing the project, including autoload, code refactoring, etc.
