Alessandro Nadalin has posted a two part series to his site to help you get the Twig templating tool integrated with your legacy codebase.

It might happen that you are working on a legacy code that is years old, with its own templating mechanism1 that doesn't really allow you to take advantage of the benefits that a structured and object-oriented engine like Twig. In this situations, when a complete replacement would cost too much to your organization, you can take advantage of a wild integration between this advanced template engine and your existing code.

In the first part of the series, he proposes integrating it at the base level, essentially wrapping the "render" method of your framework of choice. In the second part of the series, though, he comes back with a "less wild" approach that also lets you take advantage of some of the other features twig has to offer. He modifies the previous example to output a template file and reuse that in the Twig "render" call.

On Reddit.com a discussion has started up around a question asked about legacy application migration - things to consider when moving a large existing project onto a framework.

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.

In this post to his site, Justin Carmony shares some of his experience in working with a legacy code base and shares some of the steps he's taking in his own work to modernize it.

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.

In this new post to DZone.com Giorgio Sironi looks at a method for "recording" the request and response information for an application that might be lacking in documentation using PHP's output buffering.

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.

Laura Thompson has a quick post to her blog explaining one simple fact that all developers (or really anyone even loosely related to computing systems) should remember - all systems suck.

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.

On the Qafoo blog today there's a new article talking about testing the one thing that we as developers can fear the most - legacy code.

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.

Matt Curry has posted his review of the recently released "Refactoring Legacy Applications Using CakePHP" book from Chris Hartjes. The book looks to help developers get a better feel for using CakePHP in real-world applications.

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).

Chris Hartjes, a guru of CakePHP knowledge, is putting together a book - "Refactoring Legacy Applications Using CakePHP".

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.

Chris Hartjes continues his series looking at converting over legacy applications into a CakePHP environment with this third part, a focus on what can be one of the hardest parts - separating out business logic and presentation logic.

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.

Chris Hartjes has posted the second part of his look at converting legacy applications over to a more structured CakePHP environment. In this new post he looks at working with the database schema.

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.