I am working for an online store that has a codebase which has spanned dozens of developers and has been constantly upgraded. The codebase has its problems but it is not too bad. I would love to put it onto a framework like laravel and systematically start cleaning up as I go, but I am unsure if it will work trying to shove a framework into the current site. Has anyone done something similar, it would take me months to rewrite the whole system, has anyone done something like this successfully? Any advice would be appreciated.

There's lots of good recommendations made in the comments including:

• "If it were me, I'd take a step back before trying to build on top of a framework. I'd start by refactoring the existing codebase out into PSR-0 compliant namespace."
• "In my experience you only rewrite an entire application if what you have has become too expensive to maintain. At this point it is actually more cost effective to rewrite it using a framework."
• "We have recently moved our website to the Symfony2 framework at my company [...] it definitely is not a one programmer job."
• "Whatever you do, replace one bit at a time. And always strive to de-couple code."

Read up on the rest of the responses or add your own to the post.

There is [still] one big piece written in a less than ideal system. Its still PHP, but much more hacked together. It is our backend CMS system for controlling the website. It is painful to use, and we get many complaints all the time about it. [...] on Twitter, I saw a link for a talk Paul M. Jones gave at the Nashville PHP Usergroup. It was entitled: "It Was Like That When I Got Here: Steps Toward Modernizing a Legacy Codebase." I couldn't think of a better title for that talk, nor a better talk to listen to at this very moment.

He mentions the steps he taking to further advance his own project towards a better, non-legacy state including an audit of the current functionality and getting input from users as to which features give them the most pain.

Using these lists to decide what to refactor, we can get the biggest gains for the least amount of work. If we were to rebuild, we would get the smallest gains (if any) of barely having something functional with the greatest effort.

So you've got this big ball of code. You don't even know how to call all of these scripts, but the code is in production and works just fine (until you have to change even a single line). How to define some characterization tests that describe how the .php scripts work now? [...] If tests do not exist, we do not know if they expect GET or POST requests, which parameters they contain, and above all what their response should be in correct and error cases. Even if all the links and calling code are under your control, it may be faster to go for the recording approach. If other applications and machines call your .php files, it is your only choice.

He suggests using ob_start and the output buffering methods to handle the recording as it lets us define a callback (or in his case, a recording object). He includes an abstract version of it, showing how to implement a "Tape" class and a "record" method to handle the data and push it into a log or some other recording mechanism.

I've been thinking a lot about this idea lately. I've spent a lot of years as an engineer and consultant fixing other people's systems that suck, writing my own systems that suck, and working on legacy systems, that, well, suck. Don't let anyone fool you. All systems suck, to a greater or lesser extent

She presents her "slightly jaded" points of view about legacy systems, current systems and ones yet to be built nothing that, no matter how impressive and well-planned out they are, they'll still suck (some maybe just a bit less than others).

Here's the punchline: sucking is like scaling. You just have to keep on top of it, keep fixing and refactoring and improving and rewriting as you go. Sometimes you can manage the suck in a linear fashion with bug fixes and refactoring, and sometimes you need a phase change where you re-do parts or all of the system to recover from suckiness.

Today we know about the benefits of Test Driven Development and normally also start new projects using TDD. Most projects from the last couple of years integrated this method in their daily development process, which often results in in good code coverage results of 90% and above. But what about all the other old projects, you still manage in your daily work?

They offer three possible solutions to the problem with the third being their recommended option - adding tests to the code as we have to change it. This can still lead to a code base with less than ideal coverage numbers so they've developed a new tool, PHP_ChangeCoverage, that creates a new kind of report based on a timeframe rather than an overall codebase coerage. You can see an example of the report here (versus this). Installation instructions are also included.

Shortly after Chris Hartjes released his new book Refactoring Legacy Applications Using CakePHP he contacted me and asked if I'd be willing to review it. I jumped at the chance and Chris emailed me the DRM free PDF. After posting it to The PirateBay, I settled in and gave it a read.

Overall, Matt found the content of the book good but had a few things he might change - the "too smooth" nature of the update to CakePHP and the inclusion of a "partial refactoring" section (one that talked about only updating part of an application to the framework and integrating it with the rest of the site).

Some of you may know that I have started writing a e-book about CakePHP. I'm planning on publishing it myself for the low, low price of $7. I thought I'd let people take a sneak peek at how it looks so far by publishing the first two chapters in very rough form.

You can find a rough draft here (pdf). Keep an eye out on Chris' blog for more (possible) preview releases and for the final product once its wrapped.

Anyway, onto other matters. As you saw in parts 1 and 2, a bug part in having a successful transition from legacy app to CakePHP is having an environment that is well suited to the use of a framework. Having laid out the groundwork for that switchover, it's time to talk about the part of a refactoring or porting that is most difficult: separating your business logic from your display logic.

He talks about fat models, skinny controllers and flexible views with some code to illustrate each. This method makes the models do most of the work while the controllers are more of a go-between for them and the views. The views, then, are pliable enough to work with whatever data might be thrown at them.

Now you've decided to convert your legacy app over to CakePHP, you will run into the first serious obstacle: your database schema. To put it bluntly, if your schema does not already account for relationships between multiple tables you are screwed. Given that CakePHP is good at generating the queries you need to pull related records in for you, you NEED that schema to contain relationships.

He talks about the importance of relationships, creating his working models and some things to get well acquainted with - ow relationships work in CakePHP, how to use Containable behavior and some good SQL to back you up should you need it.

In my rapidly dwidling spare time I have been working on a project to convert an existing site for a legal services company over to PHP. I'm *this* close to being done, so I thought I'd share what I went through to get to where I am right now. [...] So after giving the code review I was asked to do the rewrite. The client realized that they had some serious maintenance issues on their hands and were in the process of creating a new look-and-feel for the site. Being the framework guy that I am, I indicated that porting the code over to a framework would be the best way to reduce maintenance issues going forward.

The series will document the process he followed to convert the application over. In part two he'll get into the meat of things - reworking the database structure.