In a new post to his site Matthias Noback walks you down a road to dependency injection, sharing his process of migrating a codebase from static calls to a more modern, robust dependency injection pattern.

I've worked with several code bases that were littered with calls to Zend_Registry::get(), sfContext::getInstance(), etc. to fetch a dependency when needed. I'm a little afraid to mention façades here, but they also belong in this list. The point of this article is not to bash a certain framework (they are all lovely), but to show how to get rid of these "centralized dependency managers" when you need to.

He talks about this common use case of "statics everywhere" and some of the problems with coupling your code to a static way of doing things. He walks through the steps towards modernization including injecting the container itself into the controller and shifting logic out into services. He also makes suggestions on what to do when constructor injection isn't possible and how to deal with "temporal coupling".

For those out there that are new to using the Laravel framework and are a bit lost in trying to figure out its structure, Laravel News has just the article for you. In this new tutorial they give you an overview of the Laravel codebase and how you should structure your applications to keep everything organized.

Getting started in a new codebase can be very overwhelming, even more so if you are new to programming. So where do you start? Where are the places to look to learn the most about a codebase? Let’s take a look at few common areas for Laravel.

They start by talking about project documentation and how it can play a vital role in the on-boarding of developers new to the application. From there the post goes on to talk about the composer.json configuration, route configurations, service providers, tests and some additional tooling. For each item there's a paragraph or two explaining its place in a Laravel application and, in some cases, links to other resources for more information.

The php[architect] site has posted a new tutorial from editor Oscar Merida showing you how to create an autoloader for a legacy codebase using one of three options.

If you’ve inherited a legacy code base, you may find it does not use an autoloader and has an idiosyncratic directory and file hierarchy for its Classes, Interfaces or Traits. Worse yet, it might not use name spaces consistently or at all. So you can’t use a posting on Twitter. [...] In this post, I’ll detail the three solutions I found: using Composer’s classmap autoloader, Symfony classmap generator (deprecated), or Zend Framework’s ClassFileLocator.

He then goes through each of the tools mentioned above and shows how to implement them to locate class files and auto-generate the autoloader files. They each have slightly different methods of getting the class files from the current code but they all end up with basically the same result: a classmap (set of relations between classes and the files they live in).

The SitePoint PHP blog has a quick tutorial posted helping you get your application PHP 7 ready with the help of the PhpCompatibility "sniffs" for the widely used PHP_CodeSniffer tool.

Sooner or later, there will come a time when you will need to migrate your projects to different PHP versions. How will you check if you’re compatible with a PHP version different to the one you’ve been developing on?

One possibility is always to install the version of PHP we want to migrate to, run php -l or something like PHPSA to check for syntax errors, check the PHP documentation for known issues with the migration and hope for the best. Or, we can use some available third party tools to check for PHP version compatibility in our projects.

The article then introduces the PHPCompatibility set of sniffs for PHP_CodeSniffer and installing them with a "git clone" in the right Standards directory. Also included are some basics for using PHP_CodeSniffer (like the command line options) and an example of some of the output from the compatibility check. The post wraps up with a real-life example using the PHPMailer codebase and testing it for PHP 5.6 readiness.

In her most recent post Lorna Mitchell talks about her own experiences in getting a current application upgraded and ready to run on PHP7. It can best be summed up in a tweet from her: "Total lines of code change needed to make the @joindin API work on PHP7: zero"

With PHP7 looking increasingly stable (relatively speaking, it's still pre-alpha so it's VERY early days and anything could happen!), and work going well on the GoPHP7-ext project to get extensions converted, I have been thinking about the migration guides we'll need to help people upgrade their existing applications. To this end, I took the simplest project I currently have (http://api.joind.in) and gave it a whirl on PHP7, using Rasmus' PHP7 dev box. [...] All in all, it wasn't a great study of what kinds of things can go wrong when upgrading projects, because as far as I can tell with the test coverage that we have, it Just Works (TM).

She points out that a major contributing factor to it "just working" in PHP7 probably has to do with the few amount of dependencies. She also suggests looking at the tools you do use and see if they're already doing work to make it cooperate on PHP7 when the time comes. She describes some codebases that should "just work" with PHP7 including smaller codebases and things created with more modern tools/libraries/frameworks/etc.

In a new post to his site Ben Ramsey shares a few suggestions around things to ask and do to learn a new codebase (whether that means in a new job or coming into a new open source project).

A few days ago, my friend Ed Finkler started a new job. Earlier this week, he posted on Twitter: "First days humble us all." Having begun a new job myself, I shared Ed’s sentiment. Last weekend, while at the Madison PHP Conference, we were discussing what developers can do during the interview process to get an idea of the kind of codebase a company has.

He includes a few questions for developers to ask, either during the interview or once hired, about the codebase itself including:

• what coding standards the company follows
• how much of the code is covered by tests
• have the company’s deployment process described

He also recommends learning the codebase by diving in and either writing tests for untested areas or work through bug reports and fix (then test) them.

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.

Stefan Koopmanschap has written up an article on the Leaseweblabs.com blog about migrating a Symfony 1 application to Symfony2 in a (slightly) less painful way that making the move all at once.

It is much easier to do a gradual migration. Start with one part of your application, and bit by bit migrate your logic and application. The traditional way of doing such migrations is to create a new project and have parallel development on the old and the new version of the application. The problem with this, though, is that when you make a change to your old application, you have to make the same change in the new codebase, essentially doubling the amount of work for each feature you need to implement. [...] You could wrap your old application into your Symfony2 application, and have different parts of your application be handled by different versions of your codebase.

With the help of a bundle he created, IngewikkeldWrapperBundle that handles the rerouting of your requests based on where the requested resource exists (in the Symfony 1 or 2 codebase).

Cal Evans has posted the eighth tip in his six-tip series (but who's counting) about how a client can coordinate better with a developer and make a better relationship for the project. In this new tip, he suggests that the client "own it".

No, I’m not talking about own it as in Point 7 - "Do your part", I mean make sure that at the end of the project, you own the project, not your developer.

He mentions two of the aspects you, the client, will need to worry about once the last line of bug free code has been committed and delivered. Be sure that you own the domain name for the project and have a clear understanding of any intellectual property concerns that might come up (what codebase is it built on, who owns the code - client or developer, etc).

In a recent post to his site Keith Casey mentions something that should be obvious to most software developers (and managers of developers out there) but is easy to forget - technical debt doesn't just disappear, even if the related resources change dramatically.

Just because you set a codebase aside and do it the "right" way, your problems don't disappear. The same bugs that annoyed people yesterday will be there today and tomorrow. In fact, when the bugs are still there a week, month, or year from now, they move beyond annoyances and into frustrations as people think (or say) things like "this has been broken for years.. why haven't they fixed it!?"

He notes that, while tossing the entire codebase out the window and starting over again (a move very, very rarely shown a good idea), you'll still end up with issues - this time involving resources and the work needed to sift through all of the bugs in the new code.