3

I was assigned to extend (and eventually maintain) a legacy system (mostly procedural, semi-ball of mud) without MVC. Any tips or suggestions for me going forward? :S

Henry
  • 289
  • 2
  • 10
  • Hi Henry, you need to elaborate more: Stack Exchange is for questions that have specific, solvable, and practical problems. Open-ended questions like this are off-topic here. Please see [our FAQ](http://programmers.stackexchange.com/faq#dontask) for more information. –  Jul 19 '11 at 18:39
  • All sites in the network are going to require you to explain more about your problem so we can target our answers and provide some value instead of generating a list of guesses of things that might help you. If you can't provide more information, [Yahoo! Answers](http://answers.yahoo.com) might be a good alternative. –  Jul 19 '11 at 18:44
  • I think all answers provided below are great answers, and all of them solve my problem. It is stackexchange that's not letting me mark more then one answers as correct, not my fault. Not to mention there were 2 up votes. – Henry Jul 19 '11 at 18:49
  • Related: http://programmers.stackexchange.com/questions/6395/how-do-you-dive-into-large-code-bases, http://programmers.stackexchange.com/questions/29788/how-do-you-dive-into-a-big-ball-of-mud – Adam Lear Jul 19 '11 at 18:52

3 Answers3

7

Start writing test for the code now, before you make changes. This gives you a baseline of the current functionality. You are going to have a hard enough time figuring out how to add in new features, you don't want to be spending time figuring out how what you did broke something. And that is if you find out you broke it.

The automated test will give you some semblance of confidence with the current state of things. It may even indicate a few things that don't work as expected now. But most importantly, it will tell you immediately when you did something that breaks something else. If a test fails after you check in a change, you will know where you changed things and where to look for issues.

Beyond that, get as much historical information as possible. If the last person who owned the code is still there, get as much information out of their head as possible. Hopefully the code is commented and there is documentation.

unholysampler
  • 7,813
  • 1
  • 30
  • 38
  • If it wasn't even written in MVC, can I still write tests? – Henry Jul 19 '11 at 17:57
  • @Henry: You can always write tests. There may be design patterns that make testing easier, but that doesn't mean you shouldn't test in other areas. Even if it is complete black-box testing that does not test every individual unit, it is still testing that will help you catch regressions. – unholysampler Jul 19 '11 at 18:16
  • @unholysamplerL thx, but if the code uses DB as input, and mocking is not possible, does that mean.. I need to write data to DB to do regression test? – Henry Jul 19 '11 at 18:19
  • 1
    @Henry: Make a duplicate environment so that you are not testing on a database that is part of the "production" environment. Once you have done that, you can write and delete anything anything you want to the database. Since this is a database that is only used for testing, you don't have to worry about the integrity of the data. You can have the test seed data, test, then completely clean the data so each test is only affected by itself. – unholysampler Jul 19 '11 at 19:46
4

You should read the following book:

http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

I heard Michael speek at a conference and bought his book for my whole team. It boils down to writing tests, but not your normal tests. You write tests that pass regardless as to whether they are right or not. What you are trying to do is create a verification that you didn't break any existing functionality whether that functionality is right or not is a decision for the support manager.

In the book he goes into details about how to modify existing code so it's testable. Creating mocks etc. It can be a long process, but after you have a set of tests that verifies existing functionality you can start refactoring the worst code.

I was able to improve an existing product that was a big mess like this. Home brewed controller that was more Model-View than MVC. In the end we had a far more stable product and was able to really improve the reliability of the system.

Bill Leeper
  • 4,113
  • 15
  • 20
1

There are a few recommended practices depending on the rough shape of the ball of bandaids and the goals of the system.

If there is a database behind it all we have had some success with keeping the existing systems running in what ever mess they are in and doing the follwoing.

Minor tweak or correction. Fix it in the current mess.

New Subsystems.

As new larger scale (individual processes or subsystems) come along you can use these as the excuse to start migrating the system to a better world.

Create a new database and a stored view / stored proecedure layer to transform the OLD view of the world into the new view of the world (which you then program against) and a BUS to go back again. If you use the BUS to describe the intent of the users rather than the change of the data you can usually work out how to transfer the data backwards easily enough.

This allows you to build the new subsystems in your shiny new platform of choice. If its web/silverlight whatever you can, in most cases provide "launch points" from the old system that does something like

ShellExecute("NewApp;ParametersToDirectAppToNewFunction") or open in the browser to the correct URL (same concept different tech).

The old database remains the "single source of truth" for a while longer and you translate the data "Forward" into the new system automatically on triggers or pull from in when populating the new system (through an API layer in SQL or in Code).

Eventually you can eat away at more and more of the system until the old system isn't doing that much anymore and you can turn the old database and legacy system off.

NB. All of your reports should be made off the new API layer and never go directly.

This approach does require a good deal of both Business Domain knowledge and SQL / Data modelling work upfront and you need to be pretty good at performance tuning in order to make it viable ... if you good with all that, this works quite well.

If you have some say over the development schedule picking first "satellite" then "less core" screens / processes to remodel and replace, say 1 in every 3 "development sprints" will help you clear the backlog of the legacy and give you "Clients" the chance to revisit and improve the processes.

Robin Vessey
  • 1,577
  • 11
  • 14