A blog about teaching Programming to non-CompSci students by Tim Love (Cambridge University Engineering Department). I do not speak on behalf of the university, the department, or even the IT group I belong to.

Tuesday, 8 February 2011

Legacy Code

"Since most computer science majors will face the horror of being assigned to a legacy system at least once in their career, computer science education should prepare them in a more scientific fashion by perhaps incorporating code discovery techniques in a software engineering course ... [they] may come away with a greater appreciation of the need for traditional, methodical software engineering techniques, as well as styles for surveying in the messy real world of legacy code" (JCSC 25,6 (June 2010)).Mark Meyer and Kevin Mastropaolo

Many experienced programmers try to understand code in several ways - bottom-up, top-down, following the effects of a user action (e.g. deleting a character in an editor), looking at data structures, etc. Though there's no substitute for experience, some books and web pages exist.

  • "Working Effectively with legacy code", M.C.Feathers, Pearson Hall
  • Working Effectively With Legacy Code - a 12 page PDF article where he says
    The general legacy management strategy is: 
    1. Identify change points 
    2. Find an inflection point 
    3. Cover the inflection point 
        a. Break external dependencies 
        b. Break internal dependencies 
        c. Write tests 
    4. Make changes 
    5. Refactor the covered code. 
  • working with legacy code - slides of a talk

Another option is to use something like doxygen which as well as generating HTML or LaTeX files from a set of documented source files can also extract the code structure from undocumented source files by means of "include dependency" graphs, inheritance diagrams, and collaboration diagrams.

We ran a project for students many years ago where students were given code that they had to build on. The project's remained popular. We've upgraded the sample GUI code, but the rest of the code has barely changed in a decade, and we don't intended to change it. In some senses, the older it gets the better. Some student feel the need to overhaul the code (replacing error codes by exceptions, etc) and usually break it.

If you're setting up such a project you might find it hard to acquire suitable legacy. You may need to write retro-style code yourself.

No comments:

Post a Comment