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

Mark Baker:
Discharging Static #2
Apr 05, 2018 @ 10:22:09

Mark Baker continues his series looking at the use of static properties and methods in applications and how to test them. In this second part of the series he focuses more on some of the unintentional side-effects that could happen when you're trying to refactor them out.

In the first article in this series, I wrote about the problems with testing static methods in classes, and showed a few approaches that allow us to write mocks for statics. Testing classes where we have static properties is a lot harder to manage, because any changes made in any test to those properties are global, across the entire test suite, not simply the test that we are running. Static properties are part of the global state, and we can’t simply tearDown() those changes in the way that we do with instances — at least we cannot easily do so if the property has a visibility of private or protected.

He goes through an example of a refactor from a static property (essentially in the global scope) to a private property. He points out the issue of setting a static value in what seem to be separate child classes, the fact that it actually changes the base value, not the individual ones, leading to potentially unintended consequences.

His main recommendation is to avoid the use of static properties all together. Where that's no possible (like in a legacy project) he offers two potential solutions: either replace them with constants if they're never changed or changing them to instance properties.

tagged: static property series part2 refactor consequences testing

Link: https://markbakeruk.net/2018/04/03/discharging-static-2/

Tomas Votruba:
Why is Collector Pattern so Awesome
Mar 12, 2018 @ 11:53:34

In a new post to his site Tomas Votruba shares some of his thoughts about why he thinks the Collector pattern is so awesome. The Collector pattern is one of many design patterns that can be used to create well-structured applications.

I already wrote about Collector pattern as one we can learn from Symfony or Laravel. But they're so useful and underused I have need to write a more about them.

Yesterday I worked on Rector and needed an entry point to add one or more Rectors by user.

He then goes through the process he followed during the refactor and some of the questions he asked:

  • Add a Provider?
  • Use Expression Language?
  • Does Collector Scale?
  • Add Tagging?

He finishes the post with one last thought about git history and how it should "tell the story" of the refactoring.

tagged: collector pattern refactor rector tutorial

Link: https://www.tomasvotruba.cz/blog/2018/03/08/why-is-collector-pattern-so-awesome/

Pineco.de:
Little Snippets to Keep Your Code Cleaner
Mar 01, 2018 @ 09:45:25

The Pineco.de blog has a post sharing some little snippets of code that can help to keep things cleaner and perform some common operations.

Sometimes it’s harder to keep your code clean and readable than to implement some architecture in your application. We collected some snippets that may help you to refactor your code.

Their list includes code to help with:

  • array casting
  • type checking
  • removing unnecessary "if" statements

They also have several others for different languages on the snippets page of their site for Javascript, Laravel, WordPress and even an .htaccess configuration.

tagged: cleaner code snippet function array typecheck refactor tutorial

Link: https://pineco.de/little-snippets-keep-code-cleaner/

Tomas Votruba:
Rector: Part 2 - Maturity of PHP Ecosystem and Founding Fathers
Feb 26, 2018 @ 11:23:30

Tomas Votruba has posted the second part of his Reactor series on his site today. In part one he covered some of the basics of the Ractor package (a CLI tool that provides some handy helper functions for Symfony applications). In part two he covers some of the "founding fathers" and packages that he built the package on top of.

You already know What Rector does and How it works from part 1.

It's not that PHP didn't need to be updated until 2017. I surely could delegate hundreds of upgrade-hours for my whole career. So why Now?

The post then talks about the idea of "codemod" functionality like the PHP CS Fixer that changes code to bring it up to PSR-2 compliance. It then covers the package that's one of the keys to the Reactor project, the nikic/PHP-Parser package. He talks about the read/write functionality, an example of a change it might make and finishes by thanking the "founding fathers" that made those packages available.

tagged: reactor part2 series ecosystem phpcodesniffer phpcsfixer ast nikicphpparser refactor

Link: https://www.tomasvotruba.cz/blog/2018/02/26/rector-part-2-maturity-of-php-ecocystem-and-founding-fathers/

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/