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

Intracto.com Blog:
Paying Technical Debt - How To Rescue Legacy Code through Refactoring
Jan 10, 2018 @ 12:31:45

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.

tagged: technical debt rescue legacy code refactor tutorial

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

Sergey Zhuk:
ReactPHP HTTP Server Middleware
Dec 20, 2017 @ 12:29:11

Sergey Zhuk has a new post to his site showing how to define and use middleware in your ReactPHP application.

What exactly is middleware? In real application when the request comes to the server it has to go through the different request handlers. For example, it could be authentication, validation, ACL, logger, caching and so on. Consider the request-response circle as an onion and when a request comes in, it has to go through the different layers of this onion, to get to the core. And every middleware is a layer of the onion.

He starts off with a simple example of a ReactPHP-based server that just responds to all requests with a "Hello world" message. I includes some logging functionality that he then refactors out into middleware. This logging records the HTTP method used, time of the request and the URL requested - all things the code can get from the request object. Code is included showing the refactoring out to the middleware and injecting it into the ReactPHP application. He then updates it to check for the existence of a file and, if so, returns the results as a stream. Finally he covers updates to the response inside the middleware, changing the HTTP status code and content returned based on the results of various checks.

tagged: reactphp middleware tutorial refactor request response

Link: http://sergeyzhuk.me/2017/12/20/reactphp-http-middleware/

QaFoo:
How to Refactor Your Legacy Code: A Decision Matrix
Nov 29, 2017 @ 12:57:39

On the QaFoo site they've shared a post with a helpful refactoring matrix that can help you determine the best approach to handling changes to your legacy code.

When you are beginning to consider refactoring your big legacy codebase towards a new software design, then it is not uncommon to feel helpless after estimating this to be a huge terrifying 2-5 years project.

To help solve the problem of not knowing where and how to begin, we have had great success using a decision matrix to decide how each part of the legacy code should be changed in such a refactoring project.

They start with the two main factors that should influence your decisions: the rate of code change and business value of the code. This builds out the matrix and the best way forward for each option. They go through the four approaches, what they would involve and how it relates back to the rate of change/business value factors. The post ends with links to a few other articles pointing you in the right direction for starting the refactoring process.

tagged: refactor matrix approach change business explaination

Link: https://qafoo.com/blog/112_refactoring_matrix.html

Laravel News:
Dynamic templates in Laravel Blade with View::first
Sep 14, 2017 @ 10:54:11

On the Laravel News site there's a tutorial posted showing you how to use Blade's View::first functionality to dynamically show a template if it exists.

When building dynamic components or pages sometimes we want to display a custom template if it exists or otherwise fall back on a default one.

[...] We can solve this problem with a series of conditionals or by using view()->exists() to check if a custom template exists or not, however, Laravel 5.5 brings us a better and more elegant way.

A screencast of the functionality in action is included as well as a text-only version with code samples showing the previously used "if view exists" check and the refactor to use View::first instead.

This dynamic view loading feature was added to Blade in Laravel v5.5 and is a great way of keeping your controllers simple by avoiding extra conditionals when dealing with dynamic templates.
tagged: dynamic template laravel blade view first refactor laravel55

Link: https://laravel-news.com/viewfirst

Paul Jones:
Slim and Action-Domain-Responder
Aug 23, 2017 @ 11:04:19

In a post to his site Paul Jones shows how an implementation of his proposed Action-Domain-Responder pattern might look when implemented with Slim, a popular PHP microframework.

I’ve had a warm place in my heart for Slim for a long time, and especially so since recognizing the Action-Domain-Responder pattern. In this post, I’ll show how to refactor the Slim tutorial application to ADR.

One nice thing about Slim (and most other HTTP user interface frameworks) is that they are already “action” oriented. That is, their routers do not presume a controller class with many action methods. Instead, they presume an action closure or a single-action invokable class. So the Action part of Action-Domain-Responder already exists for Slim. All that is needed is to pull extraneous bits out of the Actions, to more clearly separate their behaviors from Domain and the Responder behaviors.

He then works through each piece of the example application, first extracting out the Domain logic then building a Responder to handle the user interface functionality. He combines them to replace the current functionality, pointing out that the responder can now be tested separately from the user interface (templating system).

Now, for a simple case like this, using ADR (or even webbishy MVC) might seem like overkill. But simple cases become complex quickly, and this simple case shows how the ADR separation-of-concerns can be applied as a Slim-based application increases in complexity.
tagged: slim microframework actiondomainresponder designpattern adr tutorial refactor

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

Jason McCreary:
You changed the code, you didn't refactor the code.
Jul 13, 2017 @ 11:16:27

Jason McCreary has a post with an interesting perspective about code refactoring and what it means to refactor. He suggests that just changing code isn't refactoring and that it's more about changes in the observable behavior.

There was a good discussion on Twitter yesterday regarding a code contribution to the Laravel framework. It ended with some good questions about the distinctions between “refactoring” vs “changing” code.

While I want to focus on these distinctions, let’s first focus on the code change.

He gives an example of some code from the suggested change that reduced the number of lines in a before function call that still satisfied the requirements defined by the unit tests. He suggests that, while this change allowed the method to work as expected, it was more of a "change" than a "refactor". He suggests that because the code internal to the method changed that the "observable behavior" changed because of a special case with the return value. Existing tests didn't catch the change so it was assumed the refactor was successful even when it wasn't. Adding this test and fixing the issue then resulted in a true refactor and not just a change.

Given the symbiotic relationship between refactoring and testing, some consider the tests to be the requirements. So if all tests pass, you met the requirements. I think that’s a slippery slope. For me, the definition of “refactoring” again provides the answer through its own question - did we change the observable behavior?
tagged: code change refactor opinion unittest patch laravel

Link: https://jason.pureconcepts.net/2017/07/refactor-vs-change-code/

QaFoo Blog:
Refactoring Singleton Usage to get Testable Code
Jul 11, 2017 @ 12:22:07

The QaFoo.com blog has a new post sharing a helpful hint on refactoring singletons to make them more testable. Singletons and notoriously difficult to test due to how it can potentially return an unexpected version of an object.

So your code base is littered with singletons and using them? Don't worry, you can start refactoring them out of your code base class by class and introduce increased testability at every step. This strategy is very simple to implement and the probability of breaking your code is very low, especially when you are becoming more experienced with this technique.

They give an example of a service class that uses a singleton to get an instance of the Solarium_Client class via a static method call. They show how to refactor this out into a separate method and then use the "lazy initialization" pattern to only use the singleton if the property isn't already defined. This then allows you to use a setter to inject your own client during testing (a mock most likely).

tagged: refactor testing unittest mock singleton property lazy initialization

Link: https://qafoo.com/blog/107_refactoring_singletons_testability.html

QaFoo Blog:
Five Tips to Improve Your Unit Testing
Jun 13, 2017 @ 10:52:54

The QaFoo blog has posted a new article sharing five tips to improve your unit testing of your PHP applications. Even if you're a testing veteran, there's some helpful hints in here for you.

After you got the hang of unit testing there is still so much space for improvement. In this post I want to share five tips with advanced testers I have seen to influence testing in the right direction.

Their list of five tips includes advice about what you should consider as a "unit", refactoring test code and writing tests for bugs. Each topic includes a brief description of the suggestion and clear steps to follow when integrating it into your testing workflow.

tagged: unittest tips improvement advice unit logic refactor utilities bugs

Link: https://qafoo.com/blog/105_five_tips_improve_unit_testing.html

QaFoo Blog:
How You Can Successfully Ship New Code in a Legacy Codebase
Apr 21, 2017 @ 13:39:13

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.

tagged: refactor ship new code legacy application tutorial

Link: https://qafoo.com/blog/101_branch_by_abstraction.html

Michael Dyrynda:
Partial model updates in Laravel
Apr 06, 2017 @ 09:44:05

Michael Dyrynda has written up a post showing the Laravel users out there how to perform partial model updates making use of the "intersect" method.

Many Laravel developers would be familiar with the helpful only method found on the request object, which allows you to specify keys to pluck from the request. Not only does this simplify your workflow, it works quite nicely when completely unguarding your models by setting protected $guarded = [];

[...] For newcomers to Laravel, you might find this suggestion dangerous, but using only means you will only pass the desired input to your model irrespective of what was passed via the request itself. [...] Adam Wathan tweeted about an approach he uncovered whilst helping somebody out when approaching partial model updates.

He shows how the method works by starting with a traditional update method call that reassigns model properties based on input (using "has" checks to ensure the property exists). He then refactors it to use the intersect method and replaces about twenty lines of code with one. He talks about the differences between using only and intersect and offers a caveat to using intersect around preserving null values on properties.

tagged: partial model update intersect only request tutorial refactor

Link: https://dyrynda.com.au/blog/partial-model-updates-in-laravel