Before we begin modernizing our application, we need to make sure we have the necessary prerequisites in place to do the work of refactoring. These are as following:
Revision control (also known as source control or version control) allows us to keep track of the prerequisites:revision control" changes we make to our codebase. We can make a change, then commit it to source control, make more changes and commit them, and push our changes to other developers on the team. If we discover an error, we can revert to an earlier version of the codebase to a point where the error does not exist and start over.
If you are not using a source control tool like Git, Mercurial, Subversion, or some other revision control system, then that's the very first thing you need to put in place. Using source control will be a great benefit to you, even if you don't modernize your PHP application at all.
I prefer Mercurial in many ways, but I recognize that Git is more widely used, and as such I must recommend Git for new users of source control systems.
While it is beyond the scope of this book to discuss how to set up and use a source control system, there are some good Git books and Mercurial books available for free.
In order to prerequisites:PHP 5.0" apply the refactorings listed in this book, we need at least PHP 5.0 installed. Yes, I know that PHP 5.0 is ancient, but we are talking about legacy applications here. It is entirely possible that the business owners have not upgraded their PHP versions in years. PHP 5.0 is the bare minimum, because that was when class autoloading became available, and we depend on autoloading as one of our very first improvements. (If for whatever reason we are stuck on PHP 4.x, then this book will be of little use.)
If we can get away with it, we should upgrade to the very latest version of PHP. I recommend using the most-recent version of PHP available to your chosen operating system. At the time of the latest update to this book, the most recent versions were PHP 5.6.11, 5.5.27, and 5.4.43.
Doing an upgrade from an older PHP version might itself entail modifying the application, as there are changes between minor versions in PHP. Approach this with care and attention to detail: check the release notes for the release and all intervening releases, look over the codebase, identify problems, make fixes, spot check locally, commit, push, and notify QA.
Throughout prerequisites: editor/IDE this book, we will be doing a lot of searching and modifying across the legacy codebase. We will need to have a text editor or IDE that allows us to find and replace text in multiple files at once. These include:
There are likely to be others as well.
Alternatively, if our CLI-fu is strong, we may wish to use grep and sed at the command line across multiple files at once.
Using a consistent prerequisites:style guide" coding style throughout the codebase is an important consideration. Most legacy codebases that I have seen are a mishmash of styles preferred by the various authors over time. One example of this kind of mishmash is the mixing of tabs and spaces for indenting code blocks: the developers early in the project used 2 spaces for indents, developers in the middle of the project used tabs, and recent developers used 4 spaces. This had the effect of putting some child blocks completely out prerequisites:style guide" of line with their parent blocks, either too much indented or not enough, making it difficult to scan for the beginning or end of a block.
We all long for a consistent, familiar coding style. There are few urges stronger than the urge to reformat an unfamiliar or undesired coding style to one that is more preferable. But modifying the existing style, no matter how ugly or inconsistent it is, can give rise to subtle bugs and behavioral changes from something as simple as adding or removing braces in a conditional. Then again, we want the code to be consistent and familiar so that we can read it with a minimum of cognitive friction.
It is tough to give good advice here. I suggest that the only reason to modify the existing style is when it is inconsistent within an individual file. If it is ugly or unfamiliar but otherwise consistent throughout the codebase, reformatting is likely to cause more problems than it solves.
If you decide to reformat, do so only as you move bits of code from one file to another, or as you move files from one location to another. This combines the large change of extraction-and-relocation with the more subtle change of style modification, and makes it possible to test those changes in a single pass.
Finally, you may want to convert to a completely new style, even though the existing one is consistent throughout the codebase. Resist that urge. If your desire to reformat in toto is overwhelming and cannot be ignored, use a publicly documented non-project-specific coding style instead of trying to create or apply your own personal or project-specific style. The code in this book uses the PSR-1 and PSR-2 style recommendations as a reflection of that advice.