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

Frederick Vanbrabant:
The Integration Operation Segregation Principle
Oct 15, 2018 @ 10:48:13

In a new post to his site Frederick Vanbrabant tackles the integration operation segregation principle. While the term sounds intimidating, it's just a long way to say something you probably already do: refactor code into smaller testable chunks.

A few weeks ago I attended a DDDBelgium meetup where I was lucky to participate in a refactor workshop lead by Pim and Joop. After the incredible workshop Pim, Dries and me were discussing some code that we refactored earlier . Not so long in the conversation the words “Integration Operation Segregation Principle” casually got dropped by Pim.

Now I’m going, to be honest with you (as I was with them), I had no idea what the hell he was talking about. And maybe neither do you.

He starts with some simple code for a "calculator" class with a calculate method to handle the pricing of a rental car. He includes the test for the class/method as well, using a mock object and several expects calls to handle the method calls. The test ends up being larger than is probably good, so he looks into refactoring the original code to abstract out some of the functionality and make it more testable. In the process this also makes the code easier to follow and, while there is more of it, more maintainable and flexible in the end.

tagged: tutorial integration operation segregation principle refactor testable unittest

Link: https://frederickvanbrabant.com/post/2018-10-08-integration-operation-segregation-principle/

Matthias Noback:
More code comments
Aug 16, 2018 @ 10:06:58

In response to a comment he saw on Twitter about comments in code, Matthias Noback has written up a post with some of his own thoughts.

Recently I read a comment on Twitter by Nikola Poša. [...] He was providing us with a useful suggestion, one that I myself have been following ever since reading "Clean Code" by Robert Martin. The paraphrased suggestion in that book, as well as in the tweet, is to consider a comment to be a naming issue in disguise, and to solve that issue, instead of keeping the comment. By the way, the book has some very nice examples of how comments should and should not be used.

Matthias starts with the suggestion that, when correctly written, code shouldn't need comments to be clear about what's happening. He encourages the use of the "refactor for clarity" method to remove comments and make the code more clear. He finishes the post by breaking down the types of comments (explanatory, todo and "wtf"), what they are/examples and in what situations they can be useful for.

tagged: code comment refactor opinion clarity types usefulness

Link: https://matthiasnoback.nl/2018/08/more-code-comments/

TechBeacon:
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/

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