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.

On the CodingItWrong site Josh Justice has written up an interesting article about the different "schools" of testing and the approaches they take. While it's not specific to PHP testing, a lot of the principles still apply.

The last few months have been my first opportunity to do automated testing at my full-time job. As I’ve been trying to get the hang of it, my biggest question has been how many of each type to test to write: how many unit, integration, and acceptance tests. Turns out Folks Got Opinions™ on this! As I researched, I found at least four different approaches to testing, and they each provide different answers to a number of questions I had.

His research answered questions about what the different types are, what processes are used to create tests and what to check for. He also answered question about how to change code based on what you find during testing and what "good code" is. HE then breaks down the rest of the article into the four different types of software testing he found during his research:

• Test Approach #1: Whatever it is DHH does.
• Test Approach #2: Classical TDD
• Test Approach #3: Mockist TDD
• Test Approach #4: Discovery Testing

Each sections includes a summary of the testing practices, links to some other resources on the topic and an illustration of the typical flow when writing the tests.

In a post to his site Matthieu Napoli shares some of his thoughts about "code style rationality" including code formatting in general and some suggestions on one of the harder things in development - naming things.

Habits are sometimes making us blind. We think X looks prettier than Y but that’s just the habit speaking. In this article I’ll try to take a rational approach at coding style. That means leaving the “it looks ugly/better” at the door.

If at any point you feel like something “just doesn’t look good”, breath in, breath out, and try it! Nothing beats hands-on experience, not even some random article on the internet.

He looks at a few subjects specifically (there's way too many to cover them all in detail):

• the use of trailing commas
• alignment of values in docblock comments
• keeping docblock comments minimal
• using the "Interface" suffix
• using the "Exception" suffix

He ends the post by reminding readers that the point is to think about code style logically and that no rules are written in stone.

The SitePoint PHP blog has a new tutorial posted showing you how Laravel Facades work and how they ("Facades") can be used in other framework types.

The Facade pattern is a software design pattern which is often used in object oriented programming. A facade is, in fact, a class wrapping a complex library to provide a simpler and more readable interface to it. The Facade pattern can also be used to provide a unified and well-designed API to a group of complex and poorly designed APIs. The Laravel framework has a feature similar to this pattern, also termed Facades. In this tutorial we will learn how to bring Laravel’s "Facades" to other frameworks.

He starts off by looking at how the Laravel framework has implemented facades through out the entire framework. He includes examples of using these facades (like the App to make a new object instance) and how the base Facade class is structured to make it work. He covers some of the basic features of the classes that extend this base and how they're aliased in the Laravel code/configuration. He then gets into using this same sort of "facade" approach to other frameworks, specifically in an app based on the Silex microframework. He lists some of the requirements and shows how to pull in the base Facade class to extend. He also integrates the aliasing code and configuration to make it simpler to use the short names rather than full namespaced versions of the classes.

As a follow-up to the IDE comparisons he's done Davey Shafik has asked the interested for a little feedback on how they think he should move forward with the more detailed reviews of each tool.

So, dear readers, I’m doing the IDE reviews for all of you guys and there’s two ways I can proceed: I can take each of the requirements and do a single post per requirement with a writeup about it in detail for each of the 4 IDEs — then I was thinking for each new IDE I try, I can hit those same points. Or I can write up specifically on a single editor at a time, covering all of the requirements and I will also then review anything else about the editor etc.

He's thinking of doing a comparison of the Eclipse-based IDEs in their own right, but wants to get feedback on what would be the most useful for other developers to learn from. Several comments have already been made suggesting approaches to the topic, other editors that might be missing from the list and some support for the Eclipse comparison idea.

Mike Weiner has put together an article for PHPBuilder.com that's posted today showing a bit more object-oriented solution to validating the user submitted data in your forms:

Whether it is for database submission, emailing, or for some other purpose, forms represent the primary means of enabling a user to send data to an application. As a result, it is important to have control over the data collected by your forms, which will aid in the creation of streamlined, error-free applications.

He lays out the validation method in a graphic going with a generic validation class that then calls the various validation methods (like phone or email) as needed. The "validation set" manages which validations are to be run on which form elements. Example code for each of the bits making up the structure and the implementation are provided.

In a new post to the Zend Developer Zone, Brett Zamir has posted a new tutorial that talks about using the Smarty templating system to create what he calls the HYSOCAMTT templating approach ("Have-Your-Separation-Of-Concerns-And-Mix-Them-Too".

This article aims to highlight a approach which allows one to separate everything from one's business logic to one's design logic, to XHTML from CSS, one's Javascript from the page structure, etc., while at the same time being able to be lazy and include, for example, CSS information within the same document (template) as one's XHTML

The tutorial uses an extension for Smarty called SmartyDocB that makes the documentation side much easier. He works through the templating process and includes some of the code for the .tpl files to get you started.

He also includes some future goals for his idea, a mention of XSL templating, XQuery and the potential for templating across programming languages to make your site even more flexible.