Chapter 1. Legacy Applications

In its simplest definition, a legacy application is any application that you, as a developer, inherit from someone else. It was written before you arrived, and you had little or no decision-making authority in how it was built.

However, there is a lot more weight to the word legacy among developers. It carries with it connotations of poorly organized, difficult to maintain and improve, hard to understand, untested or untestable, and a series of similar negatives. The application works as a product in that it provides revenue, but as a program, it is brittle and sensitive to change.

Because this is a book specifically about PHP-based legacy applications, I am going to offer some PHP-specific characteristics that I have seen in the field. For our purposes, a legacy application in PHP is one that matches two or more of the following descriptions:

• It uses page scripts placed directly in the document root of the web server.
• It has special index files in some directories to prevent access to those directories.
• It has special logic at the top of some files to die() or exit() if a certain value is not set.
• Its architecture is include-oriented instead of class-oriented or object-oriented.
• It has relatively few classes.
• Any class structure that exists is disorganized, disjointed, and otherwise inconsistent.
• It relies more heavily on functions than on class methods.
• Its page scripts, classes, and functions combine the concerns of model, view, and controller into the same scope.
• It shows evidence of one or more incomplete attempts at a rewrite, sometimes as a failed framework integration.
• It has no automated test suite for the developers to run.

These characteristics are probably familiar to anyone who has had to deal with a very old PHP application. They describe what I call a typical PHP application.