News Feed
Jobs Feed
Sections




News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

NetTuts.com:
Refactoring Legacy Code Part 1 - The Golden Master
March 24, 2014 @ 12:56:32

NetTuts.com has kicked off a new series of posts looking to help you get a handle on that big pile of legacy code you're having to work with. In part one of their "Refactoring Legacy Code" series they talk about the "Golden Master", a method of testing all the things before starting on changes.

Old code. Ugly code. Complicated code. Spaghetti code. Jibberish nonsense. In two words, Legacy Code. This is a series that will help you work and deal with it. In an ideal world, you would write only new code. You would write it beautiful and perfect. You would never have to revisit your code and you will never have to maintain projects ten years old. In an ideal world... Unfortunately, we live in a reality that is not ideal. We have to understand, modify and enhance ages-old code. We have to work with legacy code.

They start with a definition of what "legacy code" is and link to a codebase they'll guide you through for refactoring. They talk some about understanding the code and scanning through it to get an overall feel for it. They recommend some testing techniques (including the Golden Master) and include the code to create it and some of the sample output.

0 comments voice your opinion now!
tutorial refactor legacy code series part1 goldenmaster

Link: http://code.tutsplus.com/tutorials/refactoring-legacy-code-part-1-the-golden-master--cms-20331

Paul Jones:
"Page Script" As A Degenerate Controller
February 04, 2014 @ 12:26:52

In his latest post Paul Jones looks at the more legacy structure of "page controllers" (a site based on several pages rather than an MVC style) that was common before the "MVC revolution" in the PHP community years back.

Almost all of the legacy applications I've had to deal with were page-based. In doing the work to modernize them, there comes a time where the page script has been refactored to look very much like a page controller, with some distinct but not critical differences. As such, I have come to consider the typical PHP page script to be a degenerate form of a page controller. With a little imagination, I think it's easy to see why.

He talks about how, in this older situation, the web server becomes a sort of "simplified front controller+router+dispatcher" and the PHP page acts as a "controller". He suggests that, even though this structure isn't as well separated as an MVC application, it can still be organized to make it easier to maintain.

0 comments voice your opinion now!
page controller mvc legacy structure

Link: http://paul-m-jones.com/archives/5907

Paul Jones:
Book Announcement Modernizing Legacy Applications in PHP
December 10, 2013 @ 09:23:53

Based on his popular conference session "It was like that when I got there", Paul Jones has announced the release of an ebook covering the migration of legacy applications to a more recent, well-structured system. The book, "Modernizing Legacy Applications in PHP", is still in the works, though.

My upcoming book, "Modernizing Legacy Applications in PHP", [shows how to improve your application with small changes]. Using my talk "It Was Like That When I Got Here" as a starting point, I condense 15 years of fixing PHP codebases into a collection of specific steps to complete in order. As you apply these small fixes, each one building on the last, you will be able to restructure your codebase from a spaghetti mess to a testable, organized, modernized application, free of globals and mixed concerns.

If the premise sounds interesting, be sure to sign up to be notified of updates as they happen. There's also some freebies that'll come along with the subscription including a pre-publication chapter.

0 comments voice your opinion now!
modernizing legacy application ebook pauljones

Link: http://paul-m-jones.com/archives/5828

Yannick Mahe:
The Walking Dead the consequences of living with a legacy PHP framework
August 20, 2013 @ 13:51:21

Yannick Mahe has posted some thoughts (from personal experience) about living with a legacy framework and some of the consequences that come with it. In his case, it's a Symfony 1.0-based application that would require a complete rewrite to migrate even up to the Symfony 2.x range.

At our company, our main web app is based on Symfony 1.0, a PHP framework released in 2008. It was developed by a company called Sensio and open-sourced shortly after. It was a great framework when it came out, with all the good ideas from Ruby On Rails, CakePHP, etc. as well as great documentation, tutorials and a growing community.

[...] Since that framework came out, its subsequent versions, Symfony 1.1, 1.2, 1.3, 1.4 came out and died out. The 1.4 version came with a 3 year long term support promise from Sensio which ended in 2012. All the 1.X versions are based on the same overall architecture, and same principles. Sensio also released Symfony 2.0, 2.1, 2.2 and very recently, 2.3. which have a whole new architecture.

He talks about some reasons why they're not migrating (the risk involved, the product focus, etc) and some of the trials they did to see what kind of effort would be involved. He then puts some context around working with a legacy framework, pointing out that:

  • You can no longer rely on the community and time is lost figuring things out yourself
  • Documentation is harder to find
  • The ecosystem (ex. plugins) is no longer seeing new features or updates
  • The compatibility issues with newer versions of PHP
0 comments voice your opinion now!
consequences legacy framework symfony1 experience

Link: http://blog.yannickmahe.com/symfony/2013/08/19/the-walking-dead.html

Alessandro Nadalin:
Integrating Twig in Your Legacy PHP Code
June 18, 2013 @ 10:19:49

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.

0 comments voice your opinion now!
twig legacy codebase integration template render

Link: http://odino.org/integrating-twig-in-your-legacy-php-code

Reddit.com:
Moving a large existing project onto a framework
February 01, 2013 @ 12:18:13

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.

0 comments voice your opinion now!
framework legacy application opinion advice migrate


Justin Carmony:
Refactoring or Rebuilding Working with Legacy Code
August 31, 2012 @ 08:23:24

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.
0 comments voice your opinion now!
refactor legacy code process audit user feature


DZone.com:
Record and replay for testing of legacy PHP applications
June 21, 2012 @ 10:43:09

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.

0 comments voice your opinion now!
record tutorial legacy application outputbuffering


Laura Thompson's Blog:
All systems suck
May 24, 2011 @ 10:08:22

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.
0 comments voice your opinion now!
opinion suck system legacy planned


Qafoo Blog:
Testing legacy code
August 02, 2010 @ 09:26:41

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.

0 comments voice your opinion now!
test unittest legacy code phpchangecoverage phpunit



Community Events











Don't see your event here?
Let us know!


release hhvm unittest facebook opinion symfony2 composer performance security series podcast database language component application install hack framework package introduction

All content copyright, 2014 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework