Modernize a Legacy PHP Application



View Reddit by AdrienPoupaView Source

Categories: PHP

5 Comments

michaelbiberich · August 11, 2020 at 6:08 pm

Good post.

Adding to #1 you’ll also want to not use `.env` for production (either bake stuff into code/config on deploy or get it from some kind of vault).

Also worth noting: by fixing #2 you can also start to set up testing stuff and gradually introduce tests for stuff you’re about to change/fix/refactor.

nerfyoda · August 11, 2020 at 7:42 pm

This is a good list, but the author forgot step 1: make sure your app has a passing and somewhat deep integration or functional test suite. Modernizing an app shouldn’t break the app. A good test suite can guard against that.

papasmurph · August 11, 2020 at 7:44 pm

I’m using a method similar to #1, but in PHP, enabling me to set up arbitrary conditions and “trickle down effects” on the configuration. It checks domain and other conditions to control what configuration is expressed in a specific installation. That means different domains (test, staging, production) can run the exact same code (from a source code point of view) with the exact same database content, making “roll-over” very easy. I can also set global debug and performance flags for the whole system, so I could perform e.g. performance testing on staging while that flag will automatically not be set when moving to production. It works for me.

micalm · August 11, 2020 at 9:05 pm

#2 is bullshit. A well-organized `lib` is as good as `vendor`, composer just makes life a little bit easier.

#4 is sketchy. `public/` on a misconfigured server will not help you at all, `lib/` in webroot on a well configured server won’t be an issue at all. Do it right the first time on all levels.

#5 should be #1 or even #0, as fixing security issues always comes first.

A complete rewrite is not the answer 90% of the time, as the summary suggests. It’s fine for simple apps, but when you face advanced bussines logic, edge cases that someone found 5 years ago, old APIs (banks, f you) etc it’s a never-ending nightmare.

oojacoboo · August 11, 2020 at 10:13 pm

Having gone through this and the years of work it took, I can absolutely relate to the points you’ve made. There are others as well.

– Implement a DI container so you can more easily manage services and construction to keep things more uniform. Also, this will help you by having a place to encourage immutability within services.

– Implement repository services for queries. Centralizing your query logic allows for a single place to update core query logic – things like multi-tenancy get easier.

– Global exception handling. Most legacy apps don’t have a good way of handling errors. Set this up first thing, that way you’re sure you’re catching all errors, every one of them, and returning responses in a unified fashion, coupled with reliable logging. This will make everything else you do much easier. Refactoring legacy apps is highly error prone. You’ll need great error handling snd logging. Don’t skip this step.

– Be sure sure to start throwing exceptions everywhere in your code. Early and specific Exceptions make debugging easier. Start checking types and state within procedural parts of code, throwing exceptions when it’s not as expected. The more of this, the better. You’re likely dealing with too much nullable state, since that was typical of older PHP code.

– There are many other great coding patterns that are helpful. Adopting a few of these as a way to focus and clean up existing ways of handling logic, will give you a place to begin cleanup, and a motive. Factories, for example could prove very useful in cleaning up model construction. Just keep a look out for patterns.

Leave a Reply

Your email address will not be published. Required fields are marked *