What is Legacy Code? – Legacy Coder Podcast #5

What is Legacy Code?

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.

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.

Michael Feathers - Working Effectively with Legacy Code (Robert C. Martin Series) (Affiliate)*

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.

Robert C. Martin - Clean Code: A Handbook of Agile Software Craftsmanship (Affiliate)*

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.

Unit Testing Natural Applications - Legacy Coder Podcast #1

Links

Unit Testing Natural Applications – Legacy Coder Podcast #1

Unit Tests for Natural Applications with NatUnit

Unit testing with Software AG’s Natural – is that even possible? Let’s find out in the very first episode of the Legacy Coder Podcast.

Unit testing Natural applications

  • Why would I want to unit test my Natural code?
    • You get instant feedback whether your code works. That’s fun! 😀
    • You get a safety net for refactoring and optimizing your Natural code.
    • You can catch regression as early as possible. That makes evolving your code base easy and painless.
    • Unit tests can be integrated into your build process (Continuous Integration, Continuous Delivery, Continuous Deployment).
    • Unit tests are the first step on your way to a fully automated build process.
  • What tools are available for unit tests with Natural?
    • Subprogram testing within NaturalONE
      • Only subprograms can be tested.
      • Different “language” for defining your tests.
      • Tests have to be defined manually from a GUI.
      • Tests cannot be executed from within Natural itself.
      • Proprietary software maintained by Software AG.
      • Professional support by Software AG is available.
    • NatUnit – an open source framework for unit testing with Natural
      • Everything that can be called from a subprogram can be tested (subprogram, subroutine, function).
      • Tests are written in the same language that is used for production code.
      • Tests can be written as Natural code with full IDE support.
      • Tests can be executed within any Natural runtime.
      • Open source project that can be extended by everybody – including yourself.
      • There’s no professional support for the framework.
  • What do I have to do differently when writing testable Natural modules?
    • You need more fine grained modularization!
    • You have to decouple the User Interface, Database access, and the core Business Logic from each other.
    • You need to extract the functionality to test into its own callable module.

NatUnit in action

Here are a few screenshot of our NatUnit Eclipse plugin in action.

You can run a NatUnit test from within the IDE.

NatUnit Eclipse Plugin: RunAs NatUnit Test

If the tests are successful, you instantly see the famous “green bar”.

NatUnit Eclipse Plugin: Successful Test

And if the tests are broken, you’ll definitely notice that, too. 😉

NatUnit Eclipse Plugin: Failing Test

Recommended reading

Links