Are there solutions for streamlining the update of legacy code in multiple places?

Question

I'm working in some old code which was originally designed for handling two different kinds of files. I was recently tasked with adding a new kind of file to this code. Most of my problems were solved by filling out an extensive XML file with a new entry that handled everything from what lists were named to how the file is written in plural lower case. But this ended up being insufficient, as there were maybe 50 different places in 24 different code files where I had to update hardcoded switch-statements that only branched for the original two file types.

Unfortunately there is no consistency in this; there are methods which operate half from the XML file, and half off of hardcode. Some of the files which look like they would operate off of the XML file don't, and some that I would expect that I'd need to update the hardcode don't need it. So the only way to find the majority of these is to run through testing the whole system when only part of it is operational, finding that one step to fix (when I'm lucky that error logging actually tells me what is going on), and then running the whole thing again. This wastes time testing the parts of the code which are already confirmed to work, time better spent testing the new parts I have to add on top of it all.

It's a hassle and a half, and to my luck I can expect that I will have to add yet another new kind of file in the near future.

Are there any solutions out there which can aid in this kind of endeavour? Something which I can input some parameters of current features, document what points in a whole code project actually need to be updated, and run something nice the next time I need to add a new feature to the code. It needn't even be fully automated, something that'll help me navigate straight to the specific points in everything and maybe even record what kind of parameters need to be loaded.

Doubt it matters specifically, but the code is comprised of ASP.NET pages, some ASP.NET controls, hundreds of C# code files, and a handful of additional XML files. It's all currently in a couple big Visual Studio 2008 projects.

Answer 1

Not exactly what you are describing, but if you can introduce a seam into the code and lay down some interfaces you can break out and mock, a suite of unit/integration tests would go a long way to helping you modify old code you may not fully understand well.

Answer 2

I completely agree with the comment about using Michael Feathers' book to learn how to wedge new tests into legacy code. I'd also strongly recommend Refactoring, by Martin Fowler. What it sounds like you need to do for your code is to implement the "Replace conditionals with polymorphism" refactoring.

I imagine your code today looks somewhat like this:

if (filetype == 23)
{
  type23parser.parse(file);
}
else if (filetype == 69)
{
  filestore = type69reader.read(file);
  File newfile = convertFSto23(filestore);
  type23parser.parse(newfile);
}

What you want to do is to abstract away all the "if (type == foo)" kinds of logic into strategy patterns that are created in a factory.

class FileRules : pReader(NULL), pParser(NULL)
{
private:
  FileReaderRules *pReader;
  FileParserRules *pParser;
public:
  void read(File* inFile) {pReader->read(inFile);};
  void parse(File* inFile) {pParser->parse(inFile);};
};

class FileRulesFactory
{
  FileRules* GetRules(int inputFiletype, int parserType)
  {
    switch (inputFiletype)
    {
    case 23: 
      pReader = new ASCIIReader;
      break;
    case 69:
      pReader = new EBCDICReader;
      break;
    }
    switch (parserType)
    ... etc...

then your main line of code looks like this:

  FileRules* rules = FileRulesFactory.GetRules(filetype, parsertype);
  rules.read(file);
  rules.parse(file);

Pull off this refactoring, and adding a new set of file types, parsers, readers, etc., becomes as simple as writing one exclusive to your new type.

Of course, go read the book. I vastly oversimplified it here, and probably got stuff wrong, but you should get the general idea of how to approach it from this. I can also recommend another book, "Head First Design Patterns", which has a great section on the Factory patterns (if you like those "Head First" kinds of books.)