ABAP_to_the_Future

Introduction
SAP introduced ABAP Objects, the OO ve rsion of ABAP, in version 4.6, which
came out in the year 2000. After 15 years, you would expect most, if not all, ABAP
programmers to be using this style of pr ogramming. As far as I can see, nothing
could be farther from the truth. I would say that even now most new code at customer
sites (and a fair bit from SAP itself) is written in a procedural way. Some people
haven’t even started procedural programming yet and write everything in one
huge block with no subroutines. There have been huge debates on the SAP Community
Network as to whether OO programming is better than procedural. I truly
believe it is, but regardless of what I thin k, you will find that if you want to take
advantage of some of the latest advances from SAP that I describe later in this
book, then you really have no choice. If you’re new to OO, here’s a tip: The two
standout books I have read on OO programming that have actually helped me in
my day-to-day work are Clean Code and Head First Design Patterns (see the “Recommended
Reading” box at the end of this introduction). Read them!
The concept of creating antifragile prog rams was introduced by Robert Martin
(though not in those exact words), who noted how computer software tends to
rot over time: The constant changes you have to make tend to add more and more
conditional logic and the like, bloating subroutines and making the code more
and more complex until no one has any idea how to maintain it without breaking
something (i.e., it gets more brittle as time goes on). Robert Martin wants us programmers
to fight back against this sort of entropy by applying the boy scout rule,
which is “Always leave the campsite cleane r than you found it.” The idea is that
because you have to change the program anyway, make tiny changes each time to
the area you’re changing to make it clearer (i.e., rename obscure variables so you
can tell what they do, split up a huge s ubroutine into two so that it’s easier to
understand, and so on). Over time, your code base should get better instead of
slowly turning from steel to glass.
What in the world does all this have to do with the list of new goodies I’m about
to discuss? More than you might think. The traditional position has been to avoid
new tools like the plague, because they’re “risky”—that is, new. In this book, in
almost every chapter you’ll see the reverse argument popping up. I’m going to try
to show how these new tools can be used to make your programs simpler to read
or more robust: in short, more resistant to change. Why is it important to try to
shield your programs from the change s you have to make? Maybe because the
rate of change in IT has already accelerated to a breakneck speed and is only getting
faster.
25