In a post to his site Robert Basic makes an interesting suggestion about older codebases (legacy code) and how they should be handled. He suggests treating legacy code like 3rd party code.

Within the TDD community there’s an advice saying that we shouldn’t mock types we don’t own. I believe it is good advice and do my best to follow it. [...] This hidden advice is that we should create interfaces, clients, bridges, adapters between our application and the 3rd party code we use.

[...] What if we start looking at our legacy code the same way we look at the 3rd party code? This might be difficult to do, or even counterproductive, if the legacy code is in a maintenance-only mode, where we only fix bugs and tweak bits and pieces of it. But if we are writing new code that is (re)using legacy code, I believe we should look at legacy code the same way we look at 3rd party code, at least from the perspective of the new code.

He suggests that legacy code and new code should live in different parts of the application's structure and that, in order to use the legacy code, the new code should use interfaces to it rather than using it directly. He gives an example, showing the use of a User class from the legacy code and interfaces that could be used from the new code to work with it.

Tomas Votruba has a new post to his site showing how to "turn your Symfony project to legacy" through the use of action injection for mapping controllers and methods to request handling.

The other day I saw the question on Reddit about Symfony's controller action dependency injection. More people around me are hyped about this new feature in Symfony 3.3 that allows to autowire services via action argument typehints. It's new, it's cool and no one has a bad experience with it. The ideal candidate for any code you write today.

Since Nette and Laravel introduced a similar feature in 2014, there are empirical data that we learn from.

Today I'll share the experience I have from consulting few Nette applications with dangerous overuse of this pattern and how this one thing turned the code to complete mess.

He starts off with some example code, asking where the issue is showing a call to a service handler to process the an argument. This would be used when a controller is registered as a service to help reduce the amount of work to define routes and add more "magic" for request handling. While the idea sounds good, he points out some of the issues with the approach including dependency injection problems and how, if it expands outside of controllers, it can lead to a poorly written application.

In a new post to his site Matthias Noback takes a look at legacy applications and two things that most of them seem to have in common: classes that are too large and too generic methods. In this post he discusses these two topics and some of the tactics you can use to help refactor and resolve them.

I find it very curious that legacy (PHP) code often has the following characteristics:

• Classes with the name of a central domain concept have grown too large.
• Methods in these classes have become very generic.

He starts by tackling the "classes too large" problem, suggesting that it's usually just a matter of developers slowly adding to existing functionality rather than introducing large chunks of code all at once. Moving on to the "generic methods" issue, he lays out a common scenario showing how a method evolves over time to repurpose it for other uses thank its original intent. He recommends "taking a step back" and picking apart the code to make the functionality more specific in the places it's used.

Tomas Vortuba has continued his series covering the changes in the Easy Coding Standard for Symfony-based applications and the changes in version 4. In this new article he covers the updates around line breaks and legacy fixes.

Legacy code prevention, lines automated and clear naming of classes in huge projects. That all is coming to Coding Standard 4 (still in alpha).

Are you curious what work will now these 4 news fixers handle for you? Look inside.

He then goes through each of the changes and includes both the configuration changes to use it and what code changes it will make:

• Let Coding Standard handle Line Length for You
• Choose Line Length to Match Your Display
• Keep Legacy Far Away with New ForbiddenStaticFunctionSniff
• Prevent & references with ForbiddenStaticFunctionSniff
• Clear Child Class Naming Once and For All with ClassNameSuffixByParentFixer

You can find out more about the standard in this project on GitHub.

On the Delicious Brains site they have a new post that makes a suggestion to the WordPress plugin developers out there: stop supporting legacy versions of your plugins and move on.

I recently saw this tweet from Danny van Kooten which reminded me of one of the many major gripes developers have with WordPress – supporting ancient PHP versions:

"STOP SUPPORTING PHP 5.2 IN YOUR NEW PROJECTS. No one using it is actively installing plugins, trust me."

Yes, (unbelievably) WordPress still supports installations of PHP 5.2.4! As plugin developers, we can’t change that over night but we have the power to stop supporting these legacy versions in our plugins where we have control over the codebase.

He talks about how, despite the fact that the WordPress project itself strives for ultimate backwards compatibility, it's just not run on older versions of PHP as much. They share some statistics about the number of WordPress installs on each version of PHP starting with v5.2. The results show that the overwhelming majority are on v5.6 with a split between <=5.3 and >=7.0 for the remainder. They also share some statistics from their own plugins finding that the >=7.0 takes the lead.

The post then shares some of the reasons for making the upgrade to only support newer versions of the language including security updates, speed and developer experience. It finishes up with some of the steps to follow to inform users of the intent to deprecate old support and when to make the move.

Anna Filina has a quick post to her site with some recommendations around testing legacy PHP scripts giving an example of a challenge to test a controller in isolation from the rest of the application.

I gave myself a challenge: to test a legacy "controller" in isolation, yet with minimal impact on the original code.

She starts with the example code she'll be testing and then works through the steps to effectively test it:

• isolating it from the other functionality in the application
• mocking a statically called method
• requiring necessary files
• executing the controller under test

The post ends with the test class she created showing how to evaluate the result of a call with one invoice in the billing system. She makes one comment at the end to answer the question "why not just refactor" but points out that, especially in larger legacy applications, that's just not always an option.

The Intracto.com blog has a post sharing some ideas and methods about how to rescue legacy code through refactoring. In it author Door Jeroen Moons shares from his own experience working with legacy applications and offers practical advice you can apply in your own legacy codebase to "tame the beast".

I have good news for you! Squirrels plant thousands of new trees every year by simply forgetting where they leave their acorns. Also: your project can be saved.

No matter how awful a muddy legacy code mess your boss has bravely volunteered for you to deal with, there is a way out of the mire. There will be twists and turns along the way, and a monster behind every other tree. But, one step at a time, you will get there.

He starts by defining technical debt and the idea of "code cancer", those shortcuts and hacks that are taken during development and slowly corrupt the quality of the code. He then covers one of the harder parts of refactoring - persuading the customer that it's an effective use of time. He also mentions replacing current code with quality code, making problems visible, working on the hard parts and code ownership. The post finishes up with mentions of testing for quality and functional assurance, creating reusable libraries and isolating and replacing things a piece at a time.

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

In a new post to his site Robert Basic shares how some of his work on Open Source projects taught him how to better work with legacy code.

Contributing to open source projects has many benefits — you learn and you teach, you can make friends or find business partners, you might get a chance to travel. Even have a keynote at a conference, like Gary did.

Contributing to open source projects was the best decision I made in my professional career. Just because I contributed to, and blogged about Zend Framework, I ended up working and consulting for a company for four and a half years. I learned a lot during that time.

He shares some of the things that open source taught him about working with code and how it relates back to legacy code (including how to find his way around). He also tries to dispel the myth that all legacy code is bad and was "written by a bunch of code monkeys who know nothing about writing good software." He points out that, at the time the code was written, the changes may have been the best that could be done, it might be a necessary workaround or it could be an actual bug that needs fixing.

On the QaFoo blog there's a new post sharing some ideas on how you can add new code to a legacy application and ship it successfully without too much interruption to the current code.

Usually the problems software needs to solve get more complex over time. As the software itself needs to model this increased complexity it is often necessary to replace entire subsystems with more efficient or flexible solutions. Instead of starting from scratch whenever this happens (often!), a better solution is to refactor the existing code and therefore reducing the risk of losing existing business rules and knowledge.

[...] Instead of introducing a long running branch in your version control system (VCS) where you spend days and months of refactoring, you instead introduce an abstraction in your code-base and implement the branching part by selecting different implementations of this abstraction at runtime.

They then give a few examples of methods that can be use to get the new code in:

• Replacing the Backend in a CMS
• Rewriting a submodule without changing public API
• Github reimplements Merge button

The final point is broken down into the process they recommend including the refactor of the current code, starting in on the new implementation and deleting the old code.