Refactoring Journey Part 1: An initial roadmap
The company I work for is quite successful in terms of market fit and revenue, but the app itself is 10 years old. The last upgrade that was performed on this codebase was an upgrade to PHP8 and a (partial) migration to CakePHP3. These two upgrades were already quite painful and took about 6 months. Since then PHP has evolved even further and in our daily work it is becoming increasingly obvious that we're spending too much time dealing with low level issues that could be pushed to a more modern framework architecture.
I will be posting about our refactoring journey periodically, if you're also struggling with an ageing codebase, you may find some nuggets of inspiration here that may help you when you decide to modernize your application stack.
What do we want and what do we need?
As a successful business, that plans to be around for another decade (or more), there are several criteria a new framework must fulfill:
- Stability
- Extensibility
- Continous & rapid development
- Abundant and up-to-date documentation
- Vibrant Ecosystem
- Availability of experienced developers and/or consultancies.
After looking at all of these factors, we decided to go with Laravel.
Why Laravel
When dealing with PHP on an enterprise level, there are (at least in my mind) three choices:
- Wordpress
- Laravel
- Symfony
There are of course a ton of PHP frameworks out there, but most of them have very little market share and thus should not be considered for an enterprise project, unless you have very good reasons to do so. Since we don't have any such good reasons, lets focus on our shortlist and igrnore everything else.
As a first step, lets discard Wordpress right away, because it's an architectural nightmare that I won't even consider for anything more than a standard blog. If Wordpress works for you, great. But IMHO it's not suitable for an enterprise project that is essentially comprised of 100% custom functionality.
If we then look at the remaining two candidates, I believe that Laravel is the better choice. The main reason for this decision is that I believe that Laravel has reached what I would call critical mass. What I mean by this, is that Laravel - besides having a dedicated group of core developers - has an ecosystem of many independent developers who release useful addon packages all the time. These facts mean that we can be certain that Laravel will continue to be developed rapidly and that in addition to the many core packages Laravel offers, most features you would want are already available as a 3rd party addon. If you can't find exactly what you're looking for, chances are pretty good that you'll find something that is at least a partial solution to what you need and that you can then use to develop something that suits your needs.
So this is our starting point. We'll see where the journey takes us, but rest assured, while it won't be an easy or quick journey, the final destination (a clean and modern codebase running on a modern framework), will make the effort worth it.
I should also note, that I am primarily a back-end developer. When writing about this project, I will be focussing on the back-end system. Our front-end system is just has outdated and crufty as our back-end, but we have a dedicated guy for that who will work on transitioning the front-end code to VueJS. But that is not my department, so I'll ignore that part in my writings.