Minimize touching the already-working code when a radical change is required

Question

I have a code that highly relies on an Array structure like the following:

$array['customer'][$customer_id]['details'][..];    // it goes to about 10 levels deep

However, after almost two years since the initial development, now I have to include another high-level element to that array which will make it something like this:

$array['company'][$id]['customer'][..];

The challenge is that about 12,000 lines of source code are written by four programmers -- I'm the only one still working on the project, AND there is no unit tests, getters and setters, DI, etc. just a bare-bone MVC structure. So, changing the structure of that array will probably require 30% percent of methods to be modified to adapt with the new change, otherwise they just simply won't work as expected.

Is there any general approach for these kinda of headaches? Can I implement a method that could somehow bridge the gap?

I know the question is too vague without seeing the actual source code, however I highly appreciate any recommendations.

Update

Currently I'm thinking of having a method/function which returns the legacy array, however you can actually pass the desired identifier and put it in a loop to get the same effect -- I'm not certain if it will work in all cases, but hopefully will fit in most cases:

$data = get_legacy_array( $company_id );    // Instead of: $data = $array['customer']...

Answer 1

Seems like what you need to do comes down to normalizing the data structure, and simply put ['company'][$id] in front of every $array use. You could of course use find & replace (with a tool like AstroGrep), but.. Time for some terminology.

Refactoring.

Refactor first so you can warp your head around it more easily, basically restructuring the problem so its very simple to solve, then just bolt on the new functionality.

Refactoring is changing the internal codebase design to better match (new) demands. Be it performance, stability, or even readability. Adding/changing functionality could be put under the same umbrella but i would not: usually this is the thing one bolts on in a few minutes after the refactoring.

An example..

So when i refactor i do not change any functionality, i just make a place where i can easily bolt on some, at a later time. All functionality is kept identical.

I would have all lookups in that array go through a central place, a function like:

/**
 * Central customers lookup method, to aid implementing future functionality.
 * @param array $array       The original array.
 * @param Integer $companyid Optional. If given $array['company'][$companyid] must exist.
 * @return array             The $array parameter or a subset thereof.
 */
function GetCompanyCustomers($array, $companyid=null) {
  if ($companyid==null) {
    // Old approach
    return $array;
  } else {
    // Example doublechecks for debugging
    if (!isset($array['company'])) {
      echo 'Error! GetCompanyCustomers() $array["company"] does not exist.';
    }
    if (!isset($array['company'][$companyid])) {
      echo 'Error! GetCompanyCustomers() $array["company"][$companyid] does not exist.';
    }

    // New approach
    return $array['company'][$companyid];
  }
}

This facilitates the transition.

First you inject this function (and a setter, perhaps) everywhere and make sure that everything works exactly as before, then you switch to actually using $companyid. Even undoing your changes should be easy, just alter the function again. Consider making matching setter(s).

Further advise:

Its usually not a good idea to have a array that big that contains all data, that is filled again per browser request. It exposes a fundamental bad design. Unless you have to show all that data at once on one page.

Keep in mind to have your data normalized so that parts of the hiearchy are self-describing, self-contained. Use data models to fence off external access, a array may be efficient sometimes but it can bite you especially in an untyped language like PHP. What i did now with the getter could (or should..) be put in a (DataModel representing) class.

Answer 2

It looks like ArrayObject in PHP5 will allow you to create a custom class which can operate as an array, which would allow you to do horrible, horrible things such as [$foo] returning totally different things depending on context. It may not be a good idea, but I don't see why you wouldn't be able to give a smarter data access object the same interface as an array and thus have it be a drop-in replacement. At least if you are accessing based on constant strings then you should be able to change behavior with a minimum of unnecessary astonishment.