Legacy Coder Podcast

What is Legacy Code? – Legacy Coder Podcast #5

Listen Later

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!.

                          ...more
                          View all episodesView all episodes
                          Download on the App Store
                          Legacy Coder PodcastBy Legacy Coder Podcast