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.

Building on the graphing tutorial in his last post Sameer continues on looking at graphs in PHP with this new post showing how to create an "agency matrix" of a currently built graph.

Building a graph is not enough; we also need the ability to search through it. To make it easier to build search algorithms, it is useful if we can represent the graph and its connections in a different way; adjacency matrix being one such representation. An adjacency matrix is a means of representing which vertices (or nodes) of a graph are adjacent to which other vertices.

He includes some sample code to extract the data from a graph (built with the PEAR Structures_Graph package) and create a basic "table" of information about each nodes' connections.