This podcast is called “Legacy Coder” but what exactly is legacy code? I talk about my definition of the term in the fifth episode of the Legacy Coder Podcast.
Podcast: Play in new window | Download
Legacy Code?
- What is Legacy Code?
- Definition by Michael Feathers: “Code without tests.”
- Code of a certain age.
- Brown field instead of green field.
- “Old” languages or platforms.
- Natural, COBOL, ABAP, Mainframes.
- But also J2EE.
- Code that’s hard to change or maintain.
- You can write “new” legacy code.
- You can also write legacy code in modern languages like Java or C#.
- Big Balls of Mud, Monoliths.
- Duplicated code.
- Hard to separate into individual pieces of functionality for reuse.
- Different concerns are bundled together (see title image).
- Code that lacks certain quality characteristics.
- Not readable, not modularized, not consistent, hard to understand, deeply nested, similar things are done differently, no patterns.
- How can you get rid of legacy code?
- Why would you want to get rid of the code in the first place?
- “Don’t forget – having legacy software is often a sign of success. Your business was successful to last long enough for your software to become legacy.” [Sam Newman]
- High maintenance costs, aging/retiring workforce, unable to implement new requirements.
- A big rewrite is almost never the answer. But sometimes.
- Gradually improve the quality of your codebase.
- Introduce tests, e.g. compare log files before/after.
- Integrate the legacy code base into your modern architecture, e.g. with webMethods and EntireX for Adabas/Natural applications.
- Why would you want to get rid of the code in the first place?
A short piece of Legacy Code in (pseudo) Natural
Here’s how many of the old Natural modules I encounter in my day job look like:
DEFINE DATA
LOCAL USING DDMVIEW
END-DEFINE
READ IMPORTANT-DDM BY SUPERDESCRIPTOR
IF IMPORTANT-DDM.FIELD EQ 1
ADD 100 TO IMPORTANT-DDM.FIELD
UPDATE
END TRANSACTION
ELSE
ESCAPE TOP
END-IF
INPUT USING MAP 'OUTPUT'
END-READ
END
Database access, business logic, and the presentation of the results to the user (UI) are all bundled together into a single module. This becomes a maintenance nightmare quickly and is very hard to test because the individual concerns can’t be separated for testing.
This module could be split up into 5 different modules that only do one thing, can therefore be reused in different scenarios, and can easily be (unit) tested:
- Reading the database (e.g. subroutine
READ-DATA) - Processing the data, a.k.a. your “business logic” (e.g. subroutine
PROCESS-DATA) - Saving data to the database (e.g. subroutine
SAVE-DATA) - Showing the results to the user (e.g. subroutine
DISPLAY-DATA) - Orchestrating the individual steps to implement the whole use case (the main program)
Here’s how the refactored main program would look like:
DEFINE DATA
LOCAL USING ARRDATA
END-DEFINE
PERFORM READ-DATA ARRDATA
PERFORM PROCESS-DATA ARRDATA
PERFORM SAVE-DATA ARRDATA
PERFORM DISPLAY-DATA ARRDATA
END
Recommended reading (and hearing)
In his book Working Effectively with Legacy Code* Michael Feathers shows different ways of introducing automated tests into a legacy code base. He uses C++ in his examples but the underlying ideas can be applied to any other programming language, too.
*
Robert C. Martin wrote my all time favourite book for software developers: Clean Code*. If you haven’t read it already, grab a copy now and read it from front to back! No matter what programming language you’re using, you will definitely find lots of ways to improve your existing code in here.
*
In the very first episode of this podcast I talked about how to unit test your Natural application. In my opinion, that’s a very important step in modernizing a legacy code base.
