News Feed

News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way
Refactoring Legacy Code Part 9 - Analyzing Concerns
July 24, 2014 @ 11:27:56

The site has posted part nine in their series sharing helpful hints and methods for refactoring legacy code. In this new post they continue on with their example application and look at where methods should be moved to/created and mocking in their tests.

In this tutorial, we will continue to focus on our business logic. We will evaluate if RunnerFunctions.php belongs to a class and if so, to which class? We will think about concerns and where methods belong. Finally, we will learn a little bit more about the concept of mocking.

They show how to move some of the "Runner" functions from procedural to OOP, integrating them with some of the classes and methods that already exist. Tests are also included showing how it all links together. From there they get into concerns about the placement of functionality and how that relates to the work at hand. They also use Mockery to mock out some of the needed objects in their tests for the new structure.

0 comments voice your opinion now!
refactor legacy code series part6 concerns functionality mock unittest

Refactoring Legacy Code Part 8 - Inverting Dependencies for a Clean Architecture
July 10, 2014 @ 11:04:13 has posted part eight in their series looking at refactoring legacy code - Inverting Dependencies for a Clean Architecture. In this latest post they move away from just refactoring the code and start to look more at fixing the architecture of the application.

Old code. Ugly code. Complicated code. Spaghetti code. Gibberish nonsense. In two words, Legacy Code. This is a series that will help you work and deal with it. It's now time to talk about architecture and how we organize our newly found layers of code. It's time to take our application and try to map it to theoretical architectural design.

They look at the current structure of the code (well, of their refactored version) and how to apply the Dependency Inversion Principle (part of the SOLID methodology) via interfaces. The code is included for the refactor as well as tests to add to their "Golden Master" test suite to ensure continued correct functionality.

0 comments voice your opinion now!
refactor legacy code series part8 inverting dependencies

Refactoring Legacy Code Part 7 - Identifying the Presentation Layer
July 03, 2014 @ 12:57:39 has posted part seven in their "Refactoring Legacy Code" series today, continuing on with the refactor of their example application to improve maintainability and testability. In this latest article they focus in on the presentation layer.

In this seventh chapter of our refactoring tutorials, we will do a different type of refactoring. We observed in the past lessons that there is presentation related code scattered all over our legacy code. We will try to identify all the presentation related code that we can and we will then take the necessary steps to separate it from business logic.

The tutorial starts with a look at the Single Responsibility Principle (part of the SOLID design principles) and how it relates to the idea of clean architecture. They continue down the path of separating out the business logic and isolating it from the presentation layer (the display* handling). They create an "Extract" class that combines the logic and presentation though combination functionality. They walk you through the code, showing the changes you'll need to make and the tests to match.

0 comments voice your opinion now!
refactor legacy code series part7 presentation layer isolating

Refactoring Legacy Code Part 5 - Game's Testable Methods
May 27, 2014 @ 09:29:33 continues on with their next part of their refactoring series today in this new post focusing on (unit) testing more of the application. This includes both the code for the tests and the before/after of the refactored code.

Old code. Ugly code. Complicated code. Spaghetti code. Gibberish nonsense. In two words, Legacy Code. This is a series that will help you work and deal with it. In our previous tutorial, we tested our Runner functions. In this lesson, it is time to continue where we left off by testing our Game class. [...] It is much better to start testing it by its short, testable methods. This is what we'll do in this lesson: find and test those methods.

They start with creating a new "Game" object and finding the first testable method in the class. The tutorial works through this and other related methods to build up a set of "Game" tests and eventually doing some refactoring on the tests themselves. With one method down and tested, they move on to finding and creating the tests for the next few testable methods, looking for something "controllable" that makes for easy testing.

0 comments voice your opinion now!
refactor legacy code series part5 unittest game method

Refactoring Legacy Code Part 4 - Our First Unit Tests
May 19, 2014 @ 13:57:41 has posted the fourth part of their series guiding you through some recommended steps for refactoring legacy code. In this new post they build on the previous steps and focus more on the first steps into unit testing.

One of the key moments of refactoring a totally legacy code is when we start extracting small pieces from it and we start writing targeted unit tests for those small pieces. But this can be quite difficult, especially when you have code that is written so that it would be hard to compile or run if pieces of it are missing. We can't safely do large surgeries on a code we still barely understand and only a golden master test keeps us breaking it totally. Fortunately there are some techniques that can help us.

There's a brief introduction to unit testing and how it can be useful in a refactoring situation. They help you locate some isolated methods to start with and include a sample test (using PHPUnit). They talk about handling dependency injection, refactoring the tests themselves and working with dependencies across environments. Hints on isolating parts of the code that can be and how to refactor the tests to match are also included.

0 comments voice your opinion now!
refactor legacy code series part4 unittest phpunit

Refactoring Legacy Code Part 3 - Complex Conditionals
May 05, 2014 @ 10:43:20

The site has posted the third part of their series sharing some tips for refactoring the code in a legacy application. In part one they looked at the "Golden Master" and in part two about moving away from magic strings and constants.

Old code. Ugly code. Complicated code. Spaghetti code. Gibberish nonsense. In two words, Legacy Code. This is a series that will help you work and deal with it. I like to think about code just as I think about prose. Long, nested, composed sentences with exotic words are hard to understand. From time to time you need one, but most of the time, you can just use plain simple words in short sentences. This is very true for source code also.

Continuing on with this "prose" theme, he gives an example of simplification and reducing the amount of validation needed before completing the task. He compares this to complex conditionals and shares something called the "extract method" to help simplify them. He also looks at directory and file structure and suggests cleanup there as well. The tutorial finishes with a few other suggestions, things like cleaning up "runner functions" reworking negative conditionals.

0 comments voice your opinion now!
refactor legacy code series part3 conditionals complex

Refactoring Legacy Code Part 1 - The Golden Master
March 24, 2014 @ 12:56:32 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


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


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


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


Community Events

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

series symfony2 laravel experience podcast language install interview introduction opinion release developer testing code configure framework list unittest community threedevsandamaybe

All content copyright, 2014 :: - Powered by the Solar PHP Framework