What do you think?
Rate this book
Modernizing Legacy Applications in PHP
Get your code under control in a series of small, specific steps.
As you apply these incremental refactorings in order, each one building on the last, you will steadily transform your legacy PHP application from a spaghetti mess to an organized, modern, testable application, free of globals and mixed concerns.
As you apply these incremental refactorings in order, each one building on the last, you will steadily transform your legacy PHP application from a spaghetti mess to an organized, modern, testable application, free of globals and mixed concerns.
222 pages, ebook
First published May 2, 2014
10 people are currently reading
64 people want to read
About the author
Paul M. Jones
6 books2 followersPaul M. Jones is an internationally-recognized expert on PHP, performance benchmarking, and other technologies. He writes about software development, management, economics, business, politics, and culture.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 6 of 6 reviews
July 29, 2018
I've read dozens of technical books and almost all of them suffer from the same problem: lack of real-world examples and a feeling that if you apply every concept and technique described in them you will end up with a perfect piece of software. Today, I am happy to say that "Modernizing Legacy Applications in PHP" is a rare exception to this.
Developers often think that the best way to fix legacy applications is by simply rewriting it from scratch. Paul Jones thinks differently, and right at the beginning of the book he hits developers where it hurts by giving a couple of examples of famous failed attempts of complete software rewrites. Next, he talks briefly about the reasons most of such rewrite attempts fail and why refactoring is usually the best approach to modernize a legacy application. Having worked with lots of legacy applications myself, this really resonates with me. For many times I felt that throwing the old code out of the window was the only solution, and the points on the book made me understand some of the reasons why the software became like that and made me realize that most of them are non-technical and will affect a rewrite as well.
After destroying the dreams of most of the developers and arguing that refactoring is the best approach, the author guides the reader through the refactoring of a legacy PHP application. One made of dozens of includes and PHP pages, full of HTML, SQL and PHP procedural code all mixed up. A true definition of spaghetti code that I'm sure every developer has seen at least once.
As the author goes about the refactoring process, you won't really see anything that you've never seen in books like "Refactoring" and "Patterns of Enterprise Application Architecture". What really makes the book shine is the baby-steps approach in applying the ideas in these books to a sample application that is very similar to a real one. It starts by introducing the autoloading concept and how to add one to the application, as this will be the foundation for everything else in the book. With that in place, he then goes on slowly extracting pieces of code to separate classes. First, groups similar functions into classes. Quickly, but still in small steps, SQL queries go into Gateways classes, then domain logic into Transactions; presentation logic into View classes; page logic into controllers; and, finally when almost all the code was split into separate classes, a dependency injection container is introduced to glue all the pieces together.
It is interesting to note that, as it is expected of a refactoring, during the entire process the application never ceased to work. In fact, after each step, the author reminds us of the importance of coordinating with QA and notifying them about the underlying changes in the application so as to guarantee that the application still works as expected.
During the entire book, Paul is very pragmatic and down-to-earth about the process. He often tries to make it clear that the whole point is not about making the application perfect, but to make it better after each step of the way as so as to pavement the way for future improvements. At the end of the book, there is a list of many possible improvements that are still possible to implement, but it is important to remember that all of them are only now possible because of the refactoring that was made to modernize the codebase up to this point.
In my experience as a developer, I feel like that perfect code is something most people never achieve. Your knowledge about the problems you're trying to solve and the tools you use to solve them is often limited and this limit you determinate how good your solution will be. As your knowledge grows, the quality of the solutions should grow as well and constant refactoring is the way you can guarantee that this will be applied to the entire codebase. This book was a good reminder of that.
Developers often think that the best way to fix legacy applications is by simply rewriting it from scratch. Paul Jones thinks differently, and right at the beginning of the book he hits developers where it hurts by giving a couple of examples of famous failed attempts of complete software rewrites. Next, he talks briefly about the reasons most of such rewrite attempts fail and why refactoring is usually the best approach to modernize a legacy application. Having worked with lots of legacy applications myself, this really resonates with me. For many times I felt that throwing the old code out of the window was the only solution, and the points on the book made me understand some of the reasons why the software became like that and made me realize that most of them are non-technical and will affect a rewrite as well.
After destroying the dreams of most of the developers and arguing that refactoring is the best approach, the author guides the reader through the refactoring of a legacy PHP application. One made of dozens of includes and PHP pages, full of HTML, SQL and PHP procedural code all mixed up. A true definition of spaghetti code that I'm sure every developer has seen at least once.
As the author goes about the refactoring process, you won't really see anything that you've never seen in books like "Refactoring" and "Patterns of Enterprise Application Architecture". What really makes the book shine is the baby-steps approach in applying the ideas in these books to a sample application that is very similar to a real one. It starts by introducing the autoloading concept and how to add one to the application, as this will be the foundation for everything else in the book. With that in place, he then goes on slowly extracting pieces of code to separate classes. First, groups similar functions into classes. Quickly, but still in small steps, SQL queries go into Gateways classes, then domain logic into Transactions; presentation logic into View classes; page logic into controllers; and, finally when almost all the code was split into separate classes, a dependency injection container is introduced to glue all the pieces together.
It is interesting to note that, as it is expected of a refactoring, during the entire process the application never ceased to work. In fact, after each step, the author reminds us of the importance of coordinating with QA and notifying them about the underlying changes in the application so as to guarantee that the application still works as expected.
During the entire book, Paul is very pragmatic and down-to-earth about the process. He often tries to make it clear that the whole point is not about making the application perfect, but to make it better after each step of the way as so as to pavement the way for future improvements. At the end of the book, there is a list of many possible improvements that are still possible to implement, but it is important to remember that all of them are only now possible because of the refactoring that was made to modernize the codebase up to this point.
In my experience as a developer, I feel like that perfect code is something most people never achieve. Your knowledge about the problems you're trying to solve and the tools you use to solve them is often limited and this limit you determinate how good your solution will be. As your knowledge grows, the quality of the solutions should grow as well and constant refactoring is the way you can guarantee that this will be applied to the entire codebase. This book was a good reminder of that.
January 14, 2015
Excellent book. Full review available here: http://bit.ly/14AghSq
June 13, 2018
A must-read for beginners, good for intermediate. Advanced PHP programmers should know all this already.
February 5, 2017
You will find this book helpful if you are faced with laborious and challenging task of maintaining a old legacy user faced php application that was given birth and raised without any best practises in mind.
As author himself explains concept of this book perfectly:
"We started out with a spaghetti mess of a legacy application. The entire application was based in the document root, and users browsed directly to page scripts. It used an include-oriented architecture, where merely including a file caused logic to be executed. Global variables were scattered everywhere, which made debugging difficult to impossible. There were no tests of any sort, much less unit tests, so every change raised the possibility of breaking something else. There was no clear separation of model, view, and controller layers. SQL statements were embedded throughout our code, and domain logic was mixed in with presentation and action logic.
Now, after a great deal of effort, dedication, and commitment, we have modernised our legacy application. The document root consists only of public resources and a front controller. All the page scripts have been distilled into separate model, view, and controller layers. These layers are represented by a well-structured series of classes, each with its own set of unit tests. The application objects are built inside a dependency injection container, keeping their operation separate from their creation."
As author himself explains concept of this book perfectly:
"We started out with a spaghetti mess of a legacy application. The entire application was based in the document root, and users browsed directly to page scripts. It used an include-oriented architecture, where merely including a file caused logic to be executed. Global variables were scattered everywhere, which made debugging difficult to impossible. There were no tests of any sort, much less unit tests, so every change raised the possibility of breaking something else. There was no clear separation of model, view, and controller layers. SQL statements were embedded throughout our code, and domain logic was mixed in with presentation and action logic.
Now, after a great deal of effort, dedication, and commitment, we have modernised our legacy application. The document root consists only of public resources and a front controller. All the page scripts have been distilled into separate model, view, and controller layers. These layers are represented by a well-structured series of classes, each with its own set of unit tests. The application objects are built inside a dependency injection container, keeping their operation separate from their creation."
May 25, 2016
It's a nice book. Very technical, so it pass through includes/require and etc. it wqs good for me, because I could understand better some patterns and see other point of view in many cases. It contains some examples and they are linked, so you can see the evolution of the things.
February 26, 2018
It was a delightful and down to earth read when it comes to programming books. It read like a mentor telling you how to do things out of experience.
It goes through the important steps in order to tame the spaghetti - removing globals, separating domain from business logic and all the way to building a Dependency Injection container. You can see the evolution and how the ”craft is applied”.
I think the book fills an important gap between tutorials and other ”bigger” books. It doesn’t delve deep into design patterns, or try to explain their principles too much, rather it shows ”this is what we mean by these things and how we apply them in the context of legacy php”. It will lay the ground work in order to understand the next steps, or ”better-than-before” problems.
If you are seasoned programmer, especially in PHP, you propably already know this stuff, and some of the examples were a bit contrived ”FooBar doSomething()” demos, which eat the one star, but I still recommend this reading!
It goes through the important steps in order to tame the spaghetti - removing globals, separating domain from business logic and all the way to building a Dependency Injection container. You can see the evolution and how the ”craft is applied”.
I think the book fills an important gap between tutorials and other ”bigger” books. It doesn’t delve deep into design patterns, or try to explain their principles too much, rather it shows ”this is what we mean by these things and how we apply them in the context of legacy php”. It will lay the ground work in order to understand the next steps, or ”better-than-before” problems.
If you are seasoned programmer, especially in PHP, you propably already know this stuff, and some of the examples were a bit contrived ”FooBar doSomething()” demos, which eat the one star, but I still recommend this reading!
Displaying 1 - 6 of 6 reviews