On the QaFoo blog there's a new post sharing some ideas on how you can add new code to a legacy application and ship it successfully without too much interruption to the current code.

Usually the problems software needs to solve get more complex over time. As the software itself needs to model this increased complexity it is often necessary to replace entire subsystems with more efficient or flexible solutions. Instead of starting from scratch whenever this happens (often!), a better solution is to refactor the existing code and therefore reducing the risk of losing existing business rules and knowledge.

[...] Instead of introducing a long running branch in your version control system (VCS) where you spend days and months of refactoring, you instead introduce an abstraction in your code-base and implement the branching part by selecting different implementations of this abstraction at runtime.

They then give a few examples of methods that can be use to get the new code in:

• Replacing the Backend in a CMS
• Rewriting a submodule without changing public API
• Github reimplements Merge button

The final point is broken down into the process they recommend including the refactor of the current code, starting in on the new implementation and deleting the old code.

Stuart Herbert has his latest post in his "PHP Components" series on his blog today - a recommendation to include unit tests along with the release of you component.

I’m now going under the bonnet of our components, and looking at the different file roles that the PEAR installer expects to find when we distribute our component as a PEAR-compatible package. One of the most important file roles allows you to ship your tests with your package – and it’s vital that this is something that you get in the habit of doing routinely.

He recommends "testing your code and shipping your tests" along with the component(s) you're releasing. Not only does it help you create a better quality end result but also makes it simpler for other developers to make changes and know they're not breaking things. He describes unit tests for those not familiar and includes a specific example of the CommandLineLibrary and its related tests.

Tobias Schlitt has posted about the eZ Components book on his blog today - including how you can win a copy of your very own!

As you can see [below], we already got some examples and hope that everybody who ordered in advance got their examples by now, too. If you don't, stay tuned they should arrive soonish. We are both absolutely amazed by the printing quality and the overall impression of the book.

To win your own copy of the book (German) head over to this quiz page on the DynamicWebPages.de website and answer three simple questions.

Tobias Schlitt has posted about the eZ Components book on his blog today - including how you can win a copy of your very own!

As you can see [below], we already got some examples and hope that everybody who ordered in advance got their examples by now, too. If you don't, stay tuned they should arrive soonish. We are both absolutely amazed by the printing quality and the overall impression of the book.

To win your own copy of the book (German) head over to this quiz page on the DynamicWebPages.de website and answer three simple questions.