This is the second article in the eight-part series “Porting legacy PHP apps”. In this session we will explore available options for breathing new life into our legacy application. Fasten your seat belts as we continue our journey after the jump.
In the last article we have discovered that our application is at a dead end: PHP 4 has officially been declared dead, we are facing an increasing number of issues with running our application and our code is cluttered. Maintaining – and probably extending – our application is becoming a task that wastes resources and decreases our teams’ motivation to continue this piece of software.
Now we are facing a simple question: what are we supposed to do to keep our application running and our customer(s) happy?
Rewriting our application
If you have been facing the above issues for a while it may seem appealing to start from scratch and rewrite your application. A fresh start, based upon current approaches, throwing away everything we have. There even is the chance to redefine the application specification.
While this may sound good from a developers’ point of view (don’t developers love challenges), it does not smell good from a business point of view.
- Rewrites are expensive: the teams’ resources will be bound to rebuilding everything from zero, and this is expensive. Man-hours are not cheap these days, and it will be hardly possible to convince the boss(es) to invest more money compared to the current maintenance costs of your application.
- Rewrites are a waste of investments: if your application ran for a few years, there is a huge investment involved. Consider a team of three or four developers and a designer in charge for maintaining an application. It is quite an impressive number of man-hours invested, and the Euros / Dollars (or whatever you are paid in) are not earned easy. After all, throwing investments into the thrash is no Good Thing.
- Rewrites ignore existing achievements: over the years the code in your application will have matured, as you very likely faced most issues that could raise during the application lifetime. This is of value, and should not be left behind. After all it is knowledge you gained.
Refactoring your application
Refacto-what? Code refactoring describes the process of “cleaning up” your applications’ code. By refactoring we refer to modifying our existing code without touching the functionality or any defined API.
Refactoring an application comes with a few requirements for your teams’ knowledge:
- refactoring usually is tied to test-driven development. This means for every functionality you refactor, there will have to be a test defined and executed in order to verify the functionality of the refactored code. It has to deliver identical results, even though coded with a different approach.
- refactoring forces you to revisit all skeletons in the closet. All the pieces of code giving you goose bumps will make a return in your teams’ code editor of choice.
- refactoring code and authoring test cases is different. If your team is used to procedural development, test-driven development may scare your team. Probably they read about unit testing in Java, C++, C#, etc. but unit testing in PHP?
Refining your application
Porting is the most lightweight process to refine your applications. While rewriting and refactoring will include lot of code changes, porting only comes with a few changes.
If your application has been developed with PHP 4 and MySQL 4, you might make the jump and switch to PHP 5 and MySQL 5. Both versions only require minor changes to your code, and the manuals of both applications contain hints:
- Migrating from PHP 4 to PHP 5: the PHP 4 to 5 migration will only require a few code changes. It is recommended to work through the list of backward incompatible changes first
- Upgrading MySQL to MySQL 5: upgrading from 4.x to 5.x mostly consists of updates for table storage engines, and might require a change of engines, and rebuilding indexes.
Making the changes listed in the manual will require low effort, and can keep your application running for a few more years but it will not give you any benefits if you do not use new features introduced in PHP 5 and MySQL 5.
As we have seen there are a few options and the difference in effort and cost is huge. Before you decide on an option you will have to evaluate carefully what works best for you. Which option you chose will be different for every application, as no application will evolve equal to another.
In part three of our series we will develop a project plan for breathing new life into your legacy app.
Stay tuned for upcoming articles.
Comments and feedback is more than welcome, of course.