Get your code under control
in a series of small, specific steps.
There you are, working late for the second night this week. Everyone else in the office has gone home. Most of the lights are out. Yesterday you were trying to copy a feature to a different section of the site, because marketing wanted their new client to see it there. Today, you have just finished tracking down a globals-related bug in an SQL query embedded in a page script. It revealed itself only after yesterday's feature addition. You had to search across dozens of files to find it. You commit the change, push it to the common repository, and update the bug report so that QA can check on it.
As you pack up to go home for the night, you are still frustrated and worried. Who knows what new bug this fix will reveal? The work should not be this hard.
You were so excited when you got the job. The interviews went well. You clearly knew more than almost everyone else there. The other developers seemed like they really needed your help and expertise. The managers gave you a new laptop and a new LCD screen so you could be as efficient as possible. It was the perfect setup. You were eager to get to work showing off your skills and abilities to make the application sing, and get the project back on schedule.
But then you checked out the code base. It was a mess. It had been architected over several years by multiple different lead developers, and it showed. There was no consistent pattern to any of the structure. The oldest core of the system was a collection of include files that ran several levels deep. Later, someone bolted on some class-oriented libraries, and third person decided to try a framework rewrite. All of it was done in different coding styles, with different naming conventions. The codebase is full of files that contain a mixed-up aggregagation of PHP, HTML, SQL, JS, and CSS. And the "tests," such as they were, consisted of the QA team running over the site once or twice a week and filing bug reports.
Instead of that enthusiasm you had at the start, now you feel like a brand-new beginner each day. It's humiliating. Each day has been a new frustration, a new "WTF?" moment replayed in a dozen different ways. You want very much to improve the codebase, so that you can impose some sense and reason onto it, but it is such an tangled mess of spaghetti that you don't even know where to start.
It seems hopeless. Overwhelmed and drowning in bad code that you inherited from earlier developers, you feel ready to give up.
But what if I told you it didn't have to be this way? What if I told you there was a specific series of small, incremental changes you could apply steadily over time to make your PHP code better and more modern, and make your working life easier and more enjoyable? Wouldn't you like to have a plan like that written down for you, distilled into an easy-to-follow list of instructions?
My name is Paul M. Jones and my book, Modernizing Legacy Applications in PHP, does exactly that. Using my conference talk It Was Like That When I Got Here as a starting point, I condense 15 years experience in fixing PHP codebases down to a series of small, specific steps toward modernizing your application.
As you apply these incremental fixes in order, each one building on the last, you will steadily transform your codebase from a spaghetti mess to an organized, modern, testable application, free of globals and mixed concerns. And your application will continue to run as each step is completed.
The book is available at https://leanpub.com/mlaphp. Every purchase includes free updates, so as the book gets revised with updated content, that content is also yours.