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

9 ways to master awful code, fast
Jul 25, 2018 @ 10:24:58

On the TechBeacon site there's a new tutorial posted sharing a list of nine ways to master awful code and make it more efficient, easier to maintain and clearer.

You've been given the task of implementing a new feature on an old codebase, but the code looks awful. How can you understand it as quickly as possible? Here are several shortcuts to help learn the important parts of new code without getting lost in the irrelevant details.

Their suggestions range from technical to non-technical and include:

  • Ask for help
  • Make it easy to reproduce bugs (add version control, build environments)
  • Prepare for automated testing
  • At first, work on a small task

For each item in the list there's an explanation and links (or screenshots) of other resources to help illustrate their point.

tagged: master awful code refactor top9 list suggestion developer

Link: https://techbeacon.com/9-ways-master-awful-code-fast

Matthias Noback:
Road to dependency injection
Jun 12, 2018 @ 09:31:59

In a new post to his site Matthias Noback walks you down a road to dependency injection, sharing his process of migrating a codebase from static calls to a more modern, robust dependency injection pattern.

I've worked with several code bases that were littered with calls to Zend_Registry::get(), sfContext::getInstance(), etc. to fetch a dependency when needed. I'm a little afraid to mention façades here, but they also belong in this list. The point of this article is not to bash a certain framework (they are all lovely), but to show how to get rid of these "centralized dependency managers" when you need to.

He talks about this common use case of "statics everywhere" and some of the problems with coupling your code to a static way of doing things. He walks through the steps towards modernization including injecting the container itself into the controller and shifting logic out into services. He also makes suggestions on what to do when constructor injection isn't possible and how to deal with "temporal coupling".

tagged: dependencyinjection refactor codebase static inject container tutorial

Link: https://matthiasnoback.nl/2018/06/road-to-dependency-injection/

Laravel News:
Introducing View Components in Laravel, an alternative to View Composers
May 16, 2018 @ 10:55:56

On the Laravel News site there's a new post covering a refactoring of view handling that's possible with recent versions of the framework: using view components instead of view composers..

In software development, one of the “best practices” is to create reusable code that can be implemented in different parts of your application if needed. [...] View composers allow you to move the logic outside your controller and pass the data to the specified set of views. [Using view components instead of composers lets you] reuse complex components using dynamic data on any view within your application.

To help illustrate the difference they set up a scenario of a blog with a "highlights" sidebar based on data from an API response. With view composers you could extract this logic out of the controllers and add it more automatically to the view itself. They point out that this can work for a majority of the situations there's another method that is even more flexible: a reusable component implemented directly on the view. He provides the complete code showing an examples of this components, including a custom Blade directive.

tagged: laravel tutorial view composer component refactor

Link: https://laravel-news.com/introducing-view-components-on-laravel-an-alternative-to-view-composers

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/

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/

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