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

Loïc Faugeron:
Mars Rover, Driving instruction
Aug 17, 2016 @ 09:47:01

Loïc Faugeron continues his series of "Mars Rover" posts with this new article focusing on a refactor of the currently defined method of "driving" the rover.

In this series we're building the software of a Mars Rover, according to the following specifications. It allows us to practice the followings: Monolithic Repositories (MonoRepo), Command / Query Responsibility Segregation (CQRS), Event Sourcing (ES) [and] Test Driven Development (TDD).

We've already developed the first use case about landing the rover on mars, and we've started the second one about driving it. [...] In this article we're going to refactor DriveRover

He points out the reason for the refactor: there could be a desire to have more that one driving instruction in the list to execute. He starts by using phpspec to define the "Instruction" class and some tests to ensure the different directions are handled. He then moves over to the "Instruction" test and moves the code from the "DriveRover" class into it, including the valid driving directions.

tagged: mars rover tutorial series driving instruction refactor phpspec

Link: https://gnugat.github.io/2016/08/17/mars-rover-driving-instruction.html

QaFoo Blog:
Outside-In Testing and the Adapter and Facade Patterns
Jul 05, 2016 @ 10:47:03

The QaFoo blog has a post today about outside-in testing, two design patterns - Adapter and Facade - and how they relate.

As part of our workshops on Test-Driven Development we explain to our customers how testing from the outside-in can help find the right test-mix.

The technique puts a focus on test-driven-development, but instead of the traditional approach starts at the acceptance test level. The first test for a feature is an acceptance test and only then the feature is implemented from the outside classes first. [...] Outside-In testing leads to interfaces that are written from what is useful for the client object using them, in contrast to objects that are composed of collaborators that already exist. Because at some point we have to interact with objects that exist already, we will need three techniques to link those newly created interfaces/roles to existing code in our project

These three techniques are:

  • using the adapter pattern to interface with third party code
  • the facade pattern to "layer" your own code
  • continuous refactoring of interfaces/implementations

In this post they focus mostly on the adapter pattern. They show how to use it in interfacing with remote systems in a Symfony application (for example) based on a remote XML file. They also include the test to verify it's functioning correctly and the PHP code to make the mocks and interfaces you'll need for the test.

tagged: outsidein testing adapter facade designpattern refactor interface

Link: https://qafoo.com/blog/087_outside_in_testing_adapter_pattern.html

Writing advanced Eloquent search query filters
Jun 15, 2016 @ 11:10:04

In a new post from the Dotdev.co site there's a tutorial from Amo Chohan helping you write advanced search query filters for Eloquent in your Laravel application.

I recently needed to implement a search feature in an events management project I was building. What begun as a few simple options (searching by name, e-mail etc), turned into a pretty large set of parameters.

Today, I’ll go over the process I went through and how I built a flexible and scalable search system. For those of you who are eager to see the final code, head over to the Git repository to see the code.

He starts off by outlining what he'll be creating and where the need comes from for this more advanced filtering. He uses a company-wide calendar example with events and meetings/clients shown for all users. He defines the filters he knows he'll want to search by and the models relating to the data needed for those queries. He then spends the rest of the post going through the code needed to implement the filtering, starting with a rough (but working) version and refactoring from there. He moves away from the procedural method of applying filters to a query object directly and over to "applying" them more dynamically using a set of filter instances via a Decorator design pattern approach.

tagged: advanced eloquent filter search decorator apply refactor tutorial

Link: https://dotdev.co/writing-advanced-eloquent-search-query-filters-de8b6c2598db#.16sfoe3a8

QaFoo Blog:
How to Refactor Without Breaking Things
Jun 09, 2016 @ 20:31:50

On the QaFoo blog there's a new post sharing some helpful hints that you can use to refactor your code without breaking things in a legacy codebase.

Refactoring means to change the structure of your code without changing its behavior. It is an essential part of everyday programming and should become knee-jerk for your whole development team. Refactoring is very helpful to cleanup feature spikes, revise earlier decisions and keep a maintainable codebase in the long run. In a perfect project world - with extensive automated tests of various types - this is just a matter of getting used to. But there are only very few such projects. So getting into proper refactoring is much harder. This article will show you important tips to master this challenge with your team.

They point out two things that can help you ensure you break as little as possible: good tests and "baby steps". They go into a bit more detail on these two sections, mentioning how they help with the refactoring process and techniques to follow in the process.

tagged: refactor break functionality tests babysteps tutorial

Link: https://qafoo.com/blog/085_how_to_refactor_without_breaking.html

Loïc Faugeron:
Towards CQRS, Command Bus
May 12, 2016 @ 12:07:21

Loïc Faugeron has made a new post to his site talking about moving towards CQRS and Command Bus architecture in PHP applications.

By following the Command / Query Responsibility Segregation (CQRS) principle, we separate "write" logic from "read" logic. This can be applied on many levels, for example on the macro one we can have a single "Publisher" server (write) with many "Subscribers" servers (read), and on a micro level we can use this principle to keep our controllers small.

However, transitioning from a regular mindset to a CQRS one can be difficult. In this article, we'll explore the "Command Bus" pattern, to help us to get the Command (write) part right.

He starts with an example of a "create profile" happens and all logic lives in the controller. He then gets into the basics of the Command Bus handling and how the concept of "middleware" relates. He then shows how to migrate over to the Command Bus handling in his controller example, creating a CreateNewProfile command (with unit tests) and its handler. He then refactors the controller to put it to use. He points out that the initial version is tightly coupled to Doctrine so he refactors it too via some simple interfaces.

tagged: commandbus tutorial cqrs example refactor controller command handler

Link: https://gnugat.github.io/2016/05/11/towards-cqrs-command-bus.html

QaFoo Blog:
Using Mink in PHPUnit
Apr 06, 2016 @ 09:13:30

The QaFoo blog has a new post today showing you how to use Mink with PHPUnit. Mink is a testing tool that allows you to write tests as if they were happening through a browser.

Another day for a short PHPUnit trick. If you want to use PHPunit to control a browser for functional or acceptence tests, then you can easily do this using the Mink library. Mink is well known from the Behat community to facilitate Behaviour-Driven Development (BDD), but it is a standalone library that can be used with PHPUnit just as easily.

This is more flexible than using dedicated browser abstractions such as Selenium directly from PHPunit, because you can switch between different implementations or even run tests with multiple implementations using the same code base.

They start with the command you'll need to get Mink installed via Composer (a simple require) and come example code for a test on the Wikipedia site (the page about PHP). They then refactor this a bit to remove the boostrapping of the Mink client into a reusable trait, making it simpler to use in other tests. They also refactor the test to use the trait and include the phpunit.xml configuration needed to run it.

tagged: mink browser test phpunit install example trait refactor wikipedia

Link: https://qafoo.com/blog/081_phpunit_mink_functional_tests.html

Jesse Schutt:
Simplifying Conditional Expressions
Apr 04, 2016 @ 14:47:43

Jesse Schutt has posted a set of helpful hints around simplifying conditional expressions in your PHP code. This can not only make them more readable but also easier to maintain in the future.

As I’ve been reading through Refactoring by Martin Fowler, I’ve found it helpful to rewrite some of the examples from the book in PHP in order to cement the concepts into my mind. While Martin’s examples are primarily in Java, I’ve found an overwhelming majority of the concepts apply to PHP, which is where I spend most of my programming time.

In today’s article, I will attempt to rework the Simplifying Conditional Expressions (pp. 237-270) section into a handful of PHP-based examples.

He touches n a few different types of conditional refactoring and provides examples for each:

  • Decomposing the Conditional
  • Consolidate Conditional Expression
  • Consolidate Duplicate Conditional Fragment
  • Replace Nested Conditional with Guard Clause

He ends the post with a reminder about why refactoring like this is important to both you and your code:

Computers excel at taking sets of instructions and stepping through them systematically. They don’t need code to have informative method or variable names. They don’t even need the code to be formatted in a specific pattern (aside for the syntactical requirements). Our goal in simplifying conditional expressions should be to make the code read easier for humans, not for computers.
tagged: simplify conditional expression example refactor tutorial

Link: http://zaengle.com/blog/simplifying-conditional-expressions

Intracto Blog:
Paying Technical Debt - How To Rescue Legacy Code through Refactoring
Mar 17, 2016 @ 09:36:16

On the Intracto blog there's a new article posted from Jeroen Moons with some suggestions you can use to pay down technical debt in your legacy code through a bit of effective refactoring.

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 gives lost of different suggestions for things that can be done to "save your code" and make it not only easier to maintain but more flexible:

  • Persuading the customer
  • Don't replace [a huge mess] with a new one
  • Make problems visible
  • Fight what hurts most
  • Build a library

There's plenty more great suggestions here too with some thoughts and methods to back them up and help you accomplish them in your own code. If you're suffering through a large legacy codebase from day to day, I highly recommend reading through this article.

tagged: technicaldebt legacy legacycode rescue opinion method refactor

Link: http://marketing.intracto.com/paying-technical-debt-how-to-rescue-legacy-code-through-refactoring

Fixing Spaghetti: How to Work With Legacy Code
Jan 27, 2016 @ 12:09:38

On the Ethode.com blog they've shared some hints for working with legacy code to help you more effectively refactor your way out of the "spaghetti code" you might have right now. These are more general tips and aren't really PHP (or even really web application) specific but they're a good starting place for any refactoring effort.

Legacy code is software that generates value for a business but is difficult for developers to change. [...] The longer this goes on, the more frustrated customers get with the software due to quirky defects, bad user experiences and long lead times for changes. Developers are afraid to make changes due to the "Jenga effect" -- as one piece of code is changed or removed, it often leads to new defects being introduced in the system in sometimes seemingly unrelated places. This compounds into what is known as "technical debt".

They continue on talking about what "spaghetti code" is, how it can happen and some of the warning signs you can use to determine just how far down the rabbit hole you and your code are. They talk about "The Big Rewrite" everyone dreams of but points out that this is almost never a practical path. Instead they offer some good things you can do to help fix the problem: quarantining the problem, refactoring relentlessly, keeping it simple and "doing the dishes" as you go rather than letting the changes pile up.

tagged: legacy code refactor opinion advice fix software development

Link: http://www.ethode.com/blog/fixing-spaghetti-how-to-work-with-legacy-code

Loïc Faugeron:
Decouple from Frameworks
Oct 06, 2015 @ 09:48:23

In this recent post to his site Loïc Faugeron shows his support for a pretty common "battle cry" among developers that make use of one of the many PHP frameworks out there: decouple from your framework (including a few strategies how).

Frameworks solve infrastructure problems, for example how to create a HTTP or CLI application. While necessary, those concerns don't add any value to your project: the business need will not be fulfilled by creating an empty application. As always, different responsibilities mean also different reasons to change: frameworks have a history of Backward Compatibility (BC) breaks and they do so regardless of your project.

[...] Does that mean that we shouldn't use any frameworks? Should we just don't care and embrace fully frameworks? This article will explain how to avoid both extremes, by decoupling from the framework. It can be done by restricting the framework to its infrastructure responsibilities (HTTP, CLI), by only using its entry points (Controller, Command) and by using the Command Bus pattern.

He uses a simple application to illustrate his points, starting with a basic Symfony installation with PHPUnit and PHPSpec installed. He builds a listener to handle JSON encoded content input and sets up the initial "Quote" controller that will take in the new request. He follows the TDD mentality along the way, testing first then writing the code to match the test. With that system in place, he talks about the ideas of commands (from the "command bus" world) and how that could be used to refactor out the "submit" logic and make it less dependent on the framework it lives in. This lets the framework handle the low-level functionality (HTTP request/response, routing, etc) while the logic sits in a more abstract, contained location.

tagged: decouple framework opinion commandbus refactor encapsulate

Link: http://gnugat.github.io/2015/09/30/decouple-from-frameworks.html