PHP Projects…

Taken from PHP 5 Object, Patterns, and Practice by Matt Zandstra (Apress).

While there is a little technical jargon here I think that anybody who is at all involved with the development, or expansion of a web application needs to read this. I know exactly the kind of situation he is talking about…

“The problem is that PHP is just too easy. It tempts you to try out your ideas, and flatters you with good results. You write much of your code straight into your Web pages, because PHP is designed to support that. You add the heavier code to functions in library files, and before you know it you have a working Web application.

You are well on the road to ruin. You don’t realize this, of course, because your site looks fantastic. It performs well, your clients are happy, and your users are spending money.

Trouble strikes when you go back to code to begin a new phase. Now you have a larger team, some more users, a bigger budget. Yet without warning things begin to go wrong. It’s as if your project has been poisoned.

Your new programmer is struggling to understand code that is second nature to you, though perhaps a little byzantine in its twists and turns. She taking longer than you expected to reach full strength as a team member.

A simple change estimated at a day, takes three days when you discover that you must update 20 or more Web pages as a result.

On of your coders saves his version of a file over major change you made to the same code some time earlier. The loss is not discovered for three days, by which time you have amended your own local copy. It takes a day to sort out the mess, holding up a third developer who was also working on the file.

Because of the popularity of the application, you need to shift the code to a new server. The project needs to be installed by hand, and you discover that file paths, database names, and passwords are hard coded into many source files. You halt work during the move because you don’t want to overwrite the configuration changes the migration entails. The estimated two hours becomes eight as it is revealed that someone did something clever involving the Apache module ModRewrite, and the application now requires this to operate poperly.

You finally launch phase 2, and all is well. All is well for a day and a half. This first bug report comes in as you are bout to leave the office. The client phones minutes later to complain. Her report is similar to the first, but a little more scrutiny reveals that is is a different bug causing similar behavior. You remember the simple change at the start of the phase that necessitated extensive modifications throughout the rest of the project.

You realize that not all the required modifications are in place. This is either because they were omitted to start with, or because the files in question were overwritten in merge collisions. You hurriedly make the modifications needed to fix the bugs. You’re in too much of a hurry to test the changes, but they are a simple matter of copy and paste, so what can go wrong?

The next morning you arrive at the office to find that a shopping basket module has down all night. The last minute changes you made omitted a leading quotation mark, rendering the code unusable. You fix the problem, mollify the client, and gather the team for another day’s firefighting.

This everyday tale of coding folk may seem a little over the top, but I have see all these things happen over and over again. Many PHP projects start their live small and evolve into monsters.

Because the presentation layer-the PHP pages containing HTML-also contains application logic, duplication creeps in early as database queries , authentication checks, form processing, and more are copied from page to page. Every time a change is required to one of these blocks of code, it must be made everywhere the code is found, or bugs will surely follow.

Lack of documentation makes the code hard to read, and lack of testing allows obscure bugs to to undiscovered until deployment. The changing nature of a client’s business often means that code evolves away from it original purpose until it is performing tasks to which it fundamentally unsuited. Because such code has often evolved as a seething intermingled lump, it is hard, if not impossible, to switch out and rewrite parts of it to suit the new purpose”

There is good news though, it’s actually relatively easy to build an application using a solid framework and avoid these kinds of problems. It’s definitely much easier than dealing with nightmarish scenarios. It does take some extra effort at first, and good planning, but the result is all around satisfaction with nobody feeling that time or money has been wasted.

Leave a Reply