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()
orexit()
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.