Stefan Koopmanschap has shared a rant about best practices in a new post to his site. In it he shares some of his thoughts as presented in a lightning talk at the PHPAmersfoort meetup.

I have yet to talk to a developer that has told me that they were purposefully writing bad software. I think this is something that is part of being a developer, that you write software that is as good as you can possibly make it within the constraints that you have.

In our effort to write the Best Software Ever (TM) we read up on all the programming best practices: design patterns, refactoring and rewriting code, new concepts such as Domain-Driven Design and CQRS, all the latest frameworks and of course we test our code until we have a decent code coverage and we sit together with our teammates to do pair programming. And that's great. It is. But it isn't.

In the post he touches on a few main topics with his ideas for each:

• Test Coverage
• Domain-driven design
• Frameworks
• Event sourcing + CQRS
• Pair programming
• Refactoring + Rewriting

He ends the post with a suggestion to "consider all the best practices" when writing your code and developing applications. It's not just about applying them because they're defined as "best practices", it's about determining which of these practices make sense for your situation.

On thePHP.cc blog today there's a new post sharing some helpful hints related to refactoring your application to PHP 7 written up by a friend of the group, Tim Bezhashvyly.

Recently I have migrated a relatively large codebase from PHP 5.6 to PHP 7 and would like to share some of my learnings. To get the most out of this article, you should be familiar with scalar type declarations (and return type declarations). To learn about these and other features of PHP 7, I recommend the "PHP 7 Explained" eBook.

He makes the recommendation of a bold first step: enabling the strict typing on every file in your application to enforce the typing of all values. Next he recommends running your current test suite to see where the failures are. Changes are pretty high that you'll find issues with type switching and magic method handling. He suggests a method for migrating your code effectively to PHP 7: a test-driven migration. This focus works fine if your coverage is good but unless you're exercising all parts of your codebase things will unfortunately be missed.

He also points out some other changes you can make with this update including the removal of some PHPDoc annotations (you'll know the type for sure now) and modifications that may need to be made to current mock objects in your tests. There's a few other smaller things he recommends looking out for as well including the use of the "silencer" operator and exception changes.

On the SitePoint PHP blog Tobias Schlitt has an article posted that tries to answer the question "is refactoring for aesthetics worth it" for most development groups out there.

Most development teams want to get their codebase into a better, more maintainable state. But what definition of better should be chosen? In many cases, it is not necessary to dig deep into Domain Driven Design (DDD) to achieve this goal. Sometimes, it's even counter productive. But one of the most basic collections of principles can help each team a lot already: Clean Code.

The Clean Code book by Robert C. Martin summarizes many simple and advanced improvements to get better, understandable, and therefore more maintainable code.

He goes on with a bit of example code, showing a getJobs method that has room for improvement. He makes recommendations on cleanup steps like: renaming variables for clarity and breaking up code more visibly based on functionality. He then talks about the "methodology of refactoring" and how to take "baby steps" in your updates rather than major jumps. He ends by pointing out that refactoring for "beauty" sake isn't a good idea nor is doing it without a sufficient level of automated testing to ensure changes didn't break the application.

NetTuts.com has posted the second part of their "Refactoring Legacy Code" series today continuing on from their beginning of the series. They continue the refactor of their "trivia" application.

Old code. Ugly code. Complicated code. Spaghetti code. Jibberish nonsense. In two words, Legacy Code. This is a series that will help you work and deal with it. We first met our legacy source code in our previous lesson. [...] The time for the first changes have come and what better way to understand a difficult code base than start to extract magic constants and strings into variables? These seemingly simple tasks will give us greater and sometimes unexpected insights into the inner workings of legacy code. We will need to figure out the intentions of the original code author and find the proper names for the pieces of code that we've never seen before.

They talk about refactoring out things like "magic strings" and other hard-coded return values and checks. They mention updating the tests to reflect these changes while keeping an eye out for "magic constants" as well.

On DZone.com Giorgio Sironi has written up a post about some testing he's done with the ""PHP Refactoring Browser" (more on that here) on some basic code examples.

IDE proponents love, in fact, an Integrated Development Environment that provides all the functionalities you need while writing and editing code; the followers of the Unix way typically write code in Vim while augmenting it via plugins where feasible and leveraging external tools that do one thing, and do it well. [...] Automated refactorings in PHP were out of the league of Vim and Unix users; thanks to Qafoo, however, a new open source tool is able to edit code with predefined refactoring recipes: PHP Refactoring Browser.

He goes through some of the basic features and functionality of the browser, setting expectations a bit. He shows how to get it installed (via Composer) and the results of some of his testing. Rather than including them all in the post, he opted to make actual commits on github of the changes.

On the QaFoo blog today the company is introducing a new tool to help PHP developers write better, more optimized code - the PHP Refactoring Browser (written in PHP too).

Without continuous refactoring, code maintainability and extensibility will start to decrease fast, even if it has tests. Until now, only IDEs contained functionality to perform automated refactorings. And then even only PHPStorm contains the most important refactorings such as "extract method". Today we release the PHP Refactoring Browser, a refactoring tool written completely in PHP. It is based on several outstanding open-source libraries.

The browser currently supports multiple refactoring methods including the extract method, renaming of local variables and converting a local variable to an instance. They include some example code and the result from the execution of the tool. The output shows where refactoring would work best with some color coding and formatting.

You can find more about this new tool over on its github repository.

In a recent post to his site, Brandon Savage has a few helpful hints to keep in mind when you're refactoring your applications to make them easier to maintain (and possibly perform better) in the future.

The downtime [of this week] provides a perfect opportunity for the aspiring software developer to do the one thing they are always told there’s no time to do: make the code better for better’s sake. With few deadlines and plenty of free time, most developers can get a few hours of refactoring in to their code towards the end of the year. They can rearchitect sections that were implemented with haste in September; they can write tests for sections that were untested in April. Put another way, the “lost week” can be redeemed.

He has a few recommendations, each including their own brief summary:

• Test Everything First
• One Method, One Job (Also One Class, One Job)
• Don’t Be Afraid Of More Objects And Classes
• Remove Dead, Unused, Unnecessary or Old Code
• Document Your Code

Check out the full post for the summaries and links to other useful resources.

In a new post to his blog Marco Tabini offers some suggestions on unit testing - not really a tutorial on how to it, more of an "easy way in" to introducing it to your development process.

Stopping development for weeks while you figure out how to add unit tests to cover your entire codebase is simply something that cannot be done (at least, not if you want to keep your job), no matter what future benefits it might bring. The good news is, adding unit testing to your existing project only takes five minutes - which is pretty much how long it takes to get a unit testing framework installed. That's it. Move on.

He puts the emphasis on unit testing to manage change in a code base, not so much to ensure that the current application runs as it should (not initially at least). He's found them most useful in bugfixing, refactoring and when adding new functionality. Current tests (and even tests written in TDD) can help with all of these. He includes reminders that if the tests aren't written well, they're useless and that once you've started testing, it needs to be continuous, even if they're not perfect.

In a new post to his blog Devis Lucato points out something he noticed when working with objects and anonymous functions/closures - they're not all as they seem.

Both solutions allow to instantiate an anonymous object with properties. They are used as value objects and have no other purpose than storing values, so no logic can be included and they don't come with methods. They can be used as function parameters instead of arrays, for instance. PHP 5.3.0 introduced anonymous functions and closures, so it is now possible to attach functions to these VOs (*). [...] The first thing to notice is that these properties are not methods but callable functions:

In his example, an anonymous function dynamically appended to an object doesn't have access to a property set on the object just one line before. There's a way around it with call_user_func, but it's not practical. His proposed solution is to create a type of Anonymous class that uses the __call method to catch the methods and translate them into calls to call_user_func_array automatically.

When developers start graduating from just hacking together scripts and want to start looking toward the future, one thing they start thinking about is making their code the best it could be. One way to achieve this is refactoring, but where to start? Well, this new post has an introductory guide to help developers understand this powerful technique.

Recently while on a drive with a non-programmer friend, I talked with him about code complexity and manageability, how very complicated code is detrimental to productivity and stuff like that. Later on, I decided to explain it to him with actual code examples, although the most he has ever done was some HTML back in elementary school.

He starts with a basic PHP+HTML+MySQL script that mixes the three and shows how to break it apart in steps - moving the PHP away from the HTML, creating functions and making a "template" for the database fetch results to display in.