What are Legacy Systems?
The definition can range from the old, slow and not rich in functionality and may or may not work well; to the other extreme of something recent that works and works well but may be infra dig! In this sense and old assembler application as well as a relatively recently written code in C++ can be termed legacy.
There are five choices to handle a legacy application depending on its working.
- It works perfectly : Leave it as it is
- It works … But… : Need to maintain and enhance it
- It works … But… : Can it become more sociable?
- It does not work : Throw it out. Create afresh
- It does not matter :I can live without it!
The responses for a situation may vary but these are the broad categories that a situation may fall under. If there is no documentation and it is usually the case, then in all the cases excepting for the last and the first, there is a very pressing need for documentation of some kind.
The only way is to contact the original developers or some white knight who can help with a miracle. However most often the only way is to resort to creating documentation from code. Some call it code comprehension and others retro-documentation. What ever you may call it, it boils down to creating artifacts from code.
The sort of documentation would depend largely on the need and the source language followed by the style of coding the developers have resorted to.
Languages such assembler are amenable for a flowchart. Other such as COBOL a structure chart is more useful. Artifacts such a call-called graph and hence a missing inventory report are found to be useful in many cases.
Very often there is a great need to identify dead code to minimise the application footprint.
If there is an absence of an IDE for a source langauge then this exercise of retro documentation become quite a challenge. In many cases there are IDEs available especially in cases where the source langauge is C or C++ or 4GL such as PowerBuilder. These IDE have many support in extracting some meta information and to some extent this meets the need for documentation.
Whatever be the circumstances there is a need to understand code in some fashion. In my experience I have come across many situations that warrant understanding code. Some of the chief ones are:
- To estimate Code Metrics – Count of Physical / Logical lines
- To estimate Code Complexity
- To verify the completeness of code i.e., identifying dead code, missing and repeated code
- To create document artifacts