Description

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_ad]

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.

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.

Links

• Permalink for this Podcast episode
• RSS feed for the Legacy Coder Podcast
• Millennials and Mainframes in 2018 and Beyond

The post What is Legacy Code? – Legacy Coder Podcast #5 appeared first on SOA rocks!.