This is the first article in the eight-part series “Porting legacy PHP apps”. Throughout the duration of this series we will be speaking about PHP functions and language features, a little bit about XHTML and CSS, and also about client-side scripting.
As you read through the series, you might see code that could be written differently or improved. At least I do expect you to do so and comment on the articles to refine what I wrote or just tell me that I suck. After all this is intended to help commercial PHP developers, and there are a lot of us out there who would all benefit from this.
What actually is that thing you name “legacy app”?
Speaking of “legacy applications” or “legacy code” as some might say, there comes Wikipedia to the rescue with a broad definition of what we can consider to be a legacy in terms of code:
Legacy code is source code that relates to a no-longer supported or manufactured operating system or other computer technology. The term can also mean code inserted into modern software for the purpose of maintaining an older or previously supported feature.
Simply said, PHP is such a computer technology, and PHP scripts are source code after all, even though some may have considered PHP to be no real development language.
If you’re developing PHP application for a few years now, chances are good that you will have quite a few legacy applications in your companies portfolio and even a few that are still running on servers for your clients. As an example I have picked a PHP application developed for a commercial project which is dated back to mid-2000 when most of the PHP installations still were running a 3.x version of PHP and only a few early adopters made the switch to PHP4. The application is still running on a PHP 4.3.2 installation.
What about your projects?
If you are developing PHP applications for companies which sell services to consumers, chances are good that your application is still running. This is our first checkpoint for a legacy application.
What is the lifetime of your application?
Considering that PHP 4 was released in 2000, any PHP application older than five years can safely be stamped as legacy code. PHP 4.3.0 was released in December 2002, and it marked a point where the 4.x branch of PHP started to replace PHP3 installations in larger numbers.
How large is your application?
If you are using a Linux or Apple server, you can find out how many lines of code your application has pretty quickly. Open a console and enter
wc -l `find . -name *.php4 -print`
Of course, adapt the line for the file extension you used. In my case we had to
.php still was pointing to an old PHP 3 installation. In my case
this resulted in 312374 lines of code for an application that handles a few GB
of user data, and ~300K users per month.
Now if I compare this with an application – written half a year ago – that comes with stuff like unit testing, UTF8 support, full i18n localization, separation of code and views and run the above command line again, I end up with whopping 116229 lines of code. This application does leverage what PHP 5 has to offer and leaves behind functions and language features from PHP 4 which have a replacement with a different approach in PHP 5.
They say, size does not matter. I say: size matters. It’s a combination of technique and size that wins the deal. After all size should be a sign for maintainability. Even if your code is well written, the larger the code, the larger the number of maintenance tasks will become as the years pass by.
Do you see an increasing number of issue reports?
As application get older, you may start to see strange errors happening, and the number of issue reports for errors that are hard or even impossible to track will rise. PHP has gone through quite an evolution since PHP 4 was released and with PHP 5 the number of errors may grow silently.
Is your application documented?
If your application is four or five years old, it is very unlikely that you will have documented your code in a style that will be helpful today. Documentation tools like phpDoc were not broadly used and while there may have been a specification for your application, commented code will be rather rare.
Missing documentation or aged documentation may be an issue, especially when you are tasked with updating the application.
Does your application make use of libraries / frameworks?
Most likely not. PEAR was not very popular back then, and for most applications there was no defined set of libraries used. From my own backlog it seems like the focus was more on which PHP extensions were used than what libraries one may use. E.g. extensions like GD and Freetype for dynamic image creation have been on the list.
This also may be a reason for large line counts for such an application. Code had to be written in multiple places even though it was identical. Personally the only “framework” I have seen in use back then was Smarty for templates.
Does you application have style?
Even in larger teams with source code control as part of the work-flow style guides for authoring PHP code have been a rare thing on the task list. It is very likely that the team was working on one large application, where each developer was assigned to a specific part of the application, e.g. one handled templates and views, the other one handled database usage, another one was assigned to the administration system.
While this may result in code styles being adapted and used, chances are good that there will be one code style for each part of the application. If you add team changes to this, code styles will start to turn into something that lacks style aka. spaghetti code.
Does your application separate code from views?
In the early days of PHP 4 application used to mix code to implement functions with code to display output. While this may seem strange from todays’ perspective it was perfectly fine back then. PHP development was mostly done in procedural fashion, and thus application logic and user interfaces were not isolated.
Today PHP and especially PHP 5 are used more in classical fashion of software engineering, applying architectural patterns like Model-View-Controller to PHP projects.
Deprecation and your application
Within five years of time a lot of progress and evolution happens in Free Software, and PHP was no exception. Language features have changed, new features have been added, experimental PHP extensions turned into mainline extensions which are available by default. On top of that you will see a lot of PHP functions which are considered to be security risks, and have been replaced with safer functions in PHP 5.
If you are using PHP 5, there is a chapter available in the PHP manual which describes potential issues when migrating from PHP 4.
Last but not least
By now you should have an idea what the signs are to spot a legacy PHP application, and with by looking at your application’s code you should know if it is legacy or not.
In part two of our series we will continue with exploring available options for breathing new life into your legacy app.
Stay tuned for upcoming articles.
Comments and feedback is more than welcome, of course.