ABAP_to_the_Future

B
Making Programs Flexible
One of the golden rules of writing good code is make your programs flexible, and
one of the most important ways to do this is to avoid hard-coding. In a presentation
I once saw from someone from the oil company Shell, they noted, “Once you
put in electronic concrete, it is hard to get it out.” What do they mean by that? As
an example, look at the below code, whic h is fairly representative of what you
might see in an SAP program, custom or standard.
SELECT SINGLE auart
FROM vbak
INTO ld_order_type
WHERE vbeln EQ ld_order_number.
CASE ld_order_type.
WHEN 'ZX23'.
"Do Something
WHEN 'ZX99'.
"Do Something else yet again
WHEN 'ZPAB'.
"Do yet another thing
WHEN OTHERS.
"Raise an error message
ENDCASE.
This is fairly straightforw ard; the logic varies by order type. However, this is
“electronic concrete” (in OO terms, it violates the open–closed principle), because
you have to change the code in the following situations:
왘 When customizing values change
Customizing values can change over time. One day, a business analyst may create
a new order type, ZX24, which is really similar to ZX23, so the program
needs to treat it the same way. You have to change your program to say WHEN
'ZX23' OR 'ZX24'. (The removal of customizing values is less common and less
of a problem, though it can create dead branches of code that never get executed
but still get checked during an upgrade.)
왘 When customizing values are different in different systems
In this case, you might copy the program from the master system to a subsidiary’s
SAP system and find that the subs idiary has the exact same concept as a
ZX23 but calls it a Y999. You could change the hard coding in the program in
the target system or have a constant and change the value of that constant in the
711