Supporting the elderly: tips for working on a legacy PHP codebase

How many times have you started a new job to be presented with a big ball of mud to add new functionality to?

No documentation.

No version control.

No sanity.

Most of the articles and books I read often pertained to building new software. In my personal experience, however, I find my most common taskings are not building new systems but maintaining the old crumbling foundations of a business where the original architect has recently taken flight.

It’s a very real and common situation but one we don’t often talk about (unless it’s to criticize the now-departed author who is no longer present to defend themselves).

I will propose a loose guide that has previously only existed in my own headspace. I invite this to be taken with a pinch of salt and not be treated as commandments from any place of authority.

Aside from having a pillow to scream into and a copious amount of caffeine, how does one even begin to perform surgery on such a Cronenberg nightmare?

Half Splitting

The process of half splitting is a throwback to my days as a communications technician. However the fundamental principle I find very invaluable, especially when trying to find out where a fault is.

Example A. Database or code?

If you have a problem retrieving customer data. Is it the Database or is the Codebase? You might paste the SQL query directly into a MySQL client to see if its a database issue or a code issue.

Example B. Fat Controller

You might have an unfortunate script that is crashing. I once had a controller that was 45,000 lines long. No, that isn’t a typo.

It was procedural to, in the middle of an MVC framework if that makes you any unhappier.

I would not even attempt to comprehend such a monolith to poor practice. I would smash in a die() statement or an error_log() at around line 22500 and see whether the fault was still present

I would then proceed, say the session variable was incorrect still or I was getting an error: I would then probe around the 11250 line mark. So on and so forth.

Its dumb, its simple. But its often the fastest way to debug something especially if its procedurally written code.

User Acceptance Testing

I realise this is usually something you would think about when building new software, however bear with me.

As I’ve previously eluded to with the dangers of working with a big ball of mud, you never can be too careful.

I good practice that saves my sanity is I will have one or two main core pieces of functionality. The things that you will get a call at 2am if its not working. A good example in ecommerce is the ability to buy a product.

So I’ll have my trusty product that I know the price of, and I know the shipping. After any change, even before I commit to version control. I’ll plug away as if I am a customer checking out that product, adding it to basket and check nothing has changed.

It is so painfully simple and easy. I wish this was practiced by a lot of 3rd parties I have worked with, who will blindly trust their own infallibility or the fact they had no syntax errors as suitable for deployment.

File Last Modified

Have you ever seen a self-made version control system that looks like the following?

Sometimes sorting be date last modified can help you wrap your head around the thought process and which of the 20 copies you can get rid of.

Initially, whilst you are warming up there are some basic steps to take to protect yourself.

Backup everything

“Anything not saved will be lost“

– Nintendo Wii Quit Screen

If automatic backups are not already in place, then backup manually if you have to.

You want copies of:

• imagery
• databases
• code

Sometimes there might be a lot of junk mixed in with the codebase, such as adobe files from the designer, full res photos from the photographer etc.

I would prune these as you go, and definitely before you start thinking about versioning your local copy of the production directory.

Lock it down

“It’s easier to ask forgiveness than it is to get permission”

-Admiral Grace Hopper

Who else has access? Sometimes this question is hard to get an answer for. If in doubt, its easier to ask for forgiveness than permission. Just change the password and see who comes knocking in your door, and you can kindly ask what they especially need access to.

The amount of times a production FTP server is used to store shared documents or outlook archives.

If you cannot successfully pitch the use of a file sharing service such as dropbox or google drive then at least issue FTP accounts that are limited to their chosen directory. At the very least you won’t have PDF’s and email templates copied all over your codebase in error.

Version control & Local Developer Environment

“It is easy to shoot your foot off with git, but also easy to revert to a previous foot and merge it with your current leg.”

—Jack William Bell

I’ve migrated many PHP5.6 systems to the latest version, I would not even consider this if I didn’t have an environment to run my own personal copy of the codebase and data up in a controlled environment where I can test it running on different PHP versions.

The one good thing about these sprawling legacy codebases is they often run on a very simple stack (Apache, PHP, MySQL).

Because a lot of things will be connected to other things that you won’t know about, its very easy to lose critical functionality by changing something that might appear fairly innocuous. The ability to just rewind to the version before you broke everything will save yourself and your boss a lot of headaches.

If my workplace lacks any sort of workflow. A quick halfway measure, that can speed things up is to use one of the various GIT-FTP plugins (either for GIT or it might even plug into your IDE). This makes reverting a disastrous blunder even faster.

Hey, you might even get away without anyone noticing.

I realize a few readers probably shook with so much gusto that they’ve got some fresh coffee stains on their keyboards.

Obviously, if you have the means to replace an old system or refactor parts of it then you should.

These are simply a few thoughts for balancing your boss’ Jenga tower for a few more months or years until it is replaced or you have time to implement a system that does not chip away at your mental health.

As always, take it easy.

And if you can’t, take it any way you can.

Supporting the elderly: tips for working on a legacy PHP codebase
Source: Super Trending News PH