Objektoriente Programmierung mit Profis

Einmal mit Profis

Objektorientierte Programmierung (OOP) 🔗 ist alt. Angefangen hat es mit OOP in 1967 und mit Smalltalk bekannt. Troztdem war die prozeduale Programmierung bis in die 90er noch vorherrschend. Aber mit C++, Java und C# wurde OOP auch immer populärer und zählt schon seit den 2000er Jahren als der Stand der Technik. Mit C++ wird auch im ABAP Kernel entwickelt, und damit ist der Übergang zu ABAP geschafft: ABAP wurde in den 1990er um Objektorientierung erweitert. Kurz: ABAP OO gibt es auch schon seit Jahrzehnten.

Jetzt könnte man annehmen das dieses Konzept sich auch bei den ABAP Entwicklern durchgesetzt hat. In der Theorie ist es ja einfach: ABAP OO gibt ja schon seit über 30 Jahre. Die Wahrschienlichkeit das ein ABAP Dev sich ABAP OO in den letzten 30 Jahren und mit der Arbeit mit NetWeaver Systemen irgendwann angeeignet hat sollte ja wenn nicht ganz knapp, doch sogar bei 100% sein. Hätte, hätte, Fahrradkette 🔗. Oder auf Neudeutsch: reality is a bitch 🔗.

Vor nicht allzu langer Zeit wurde ein ECC System auf S/4HANA umgestellt. Das System hatte größtenteils Z-Coding und existiert um einen kleinen Teilprozess auszuführen. Der Prozess war nicht unwichtig, und damit natürlich auch das SAP System. Als das System eingeführt wurde war eine große Anzahl an Leuten involviert. Über die Zeit wurde die Anzahl immer geringer, da das Projekt in die Wartungsphase überging. Ja, auch das Budget für die Wartung wurde damit immer weniger. Es gingen ein paar Jahre ins Land und am Ende gab es nur noch einen aktiven Entwickler. Last man standing. Der Stil war dann auch wie zu erwarten: sakrosankt. Die Person hatte ja auch seit Jahren kein Nein mehr gehört, geschweige denn den Austausch mit einem weiteren Entwickler gehabt oder gesucht. Es ging dann aber darum die Lösung etwas zu erweitern, moderner zu machen, als auch nach S/4HANA zu bekommen.

Legacy coding

Die Codebasis war auf dem Stand von etwa 2010 eingefroren. Wer auf den Kalender schaut möge eventuell versucht sein zu denken: Ja gut. 2010. OData existierte schon. ABAP OO auch. WebDynpro ABAP. Vielleicht hat man ja noch etwas Schwung von damals mitgenommen und noch etwas Richtung UI5 gemacht. Ja, wäre nett gewesen, aber nein. Reports. Dnypros. FORM/PERFORM. SAP Gui Windows. Also auch die damaligen Externen haben nicht unbedingt durch weitsicht geglänzt. Im aktuellen Stand (so 2023, 2024) war, wenn ich den SAP Development Technology Radar als Referenz nehme, der komplette Tech Stack in STOP. Ja, das ist auch eine Leistung. Stolz sollte man darauf nicht unbedingt sein. Dazu alles ein einziger Monolith den nur noch der übrig gebliebene Entwickler halbwegs überblickte. Halbwegs im Sinne von: eine kleine Änderung konnte sich als wesentlich komplexer herausstellen als im worst case angenommen. Änderte man etwas an Stelle X, so ging aus welchem Grund auch immer an Stelle Z nichts mehr, obwohl beide eigentlich unabhängig voneinander waren.

Ach ja: stabil liefen die Anwendungen auch nicht. In all den Jahren seit der Inbetriebnahme der Anwendung / Lösung, gab es wohl keine Woche in der nicht irgendetwas einfach mal Fehlerfrei durchlief. Und man redet hier von einem kleinen Anwenderkreis. Für einen doch recht eng definierten Anwendungsfall. Jedoch: es klappte, irgendwie, mit Hilfe Gottes und Verzweiflung (dann halt nicht). Doch ein unbeaufsichtigter, stabiler Betrieb? Ging der Entwickler in Urlaub, so konnte der Prozess auch schon mal stehen. Das war der Stand nach vielen Jahren produktiver Betrieb und Eigententwicklung.

Objektorientiert, irgendwie, vielleicht

Ein Versuch die moderne Welt mit der Lösung zu Verbinden war ein OData Service. Bestimmte Werte werden übergeben und die dazu passenden Geschäftsobjekte zurückgegeben. Feedback des Entwicklers: kein Problem, sein Coding kann das, das ist modular aufgebaut. In der Realität sah dies dann so aus: Der OData Service wurde aufgerufen. Die Parameter ausgelesen und an eine Methode übergeben. Diese Methode tat dann folgendes:

submit zreport with params.
import mem_values = values from memory id zreport_memory.

Joaaa, also. Einen Report aufrufen und die OData Werte als Parameter übergeben. Danach die vom Report ermittelten Werte per memory id auslesen. Wo das jetzt Modular ist, keine Ahnung. Das interne Coding wo dann die Werte per export to memory id abgelegt wurden: Kraut und Rüben. Ein übergebener Parameter war auch noch der Hinweis das der Report über OData aufgerufen wird, also: der Ablauf war dann auch noch unterschiedlich zu einem normalen Aufruf des Reports und per OData. Clusterfuck bei der Fehlersuche. War halt der Versuch Spaghetticode als halbwegs modern zu verkaufen da man dann sagen konnte: OData? Kein Problem. Die Anwendung kann das. Ist doch alles Super, oder?

Die nächste Baustelle war dann natürlich bestimmte Funktionalitäten in anderen Anwendungen zu verwerten. Auch hier: Objektorientiert? Kein Problem, der Code ist schon in ABAP OO. Kurzer Erinnerung: wir reden hier von dem Report der x tausend Zeilen Code umfasste, Code der seit Jahren nicht stabil läuft, und der über und über mit FORM/PERFORM und globale Variablen für den Datenaustausch vollgstopft ist. Die Aussage das hier schon OO programmiert wurde und Funktionalitäten gekapselt vorliegen: spannend formuliert. Andererseits, ja, es gab Objekte. Und ja, es gab auch Methoden. Eine war zB. vom Namen her passend für eine Funktion. Diese get_Werte Methode wurde dann auch mal angeschaut. Und was war das Coding da drin?

submit zreport with params and return.
import mem_values = values from memory id zreport_memory_werte.

Jep, es wurde der Report wieder aufgerufen. Eine andere Memory ID ausgelesen und damit andere Werte zurückgeliefert. Aber: Objektorientiert ist das halt auch nicht. Man hat ein Monster gekapselt und die Komplexität versucht zu verstecken.

Gespräche darüber was OO ist verliefen wie zu erwarten. Interfaces? Braucht doch keiner. Vererbung? Wieso denn? Alle statisch bereitstellen in einer globalen Klasse. Das ist OO. Das ist modern. Paketkonzept? Braucht man nicht. Das ist wenn ein Senior entwickelt. Unit Tests? Ach kommt, sind wir doch ehrlich: bringt nichts, braucht man nicht, kostet nur Aufwand und Geld. Außerdem: das mit ABAP Unit hat man sich angschaut, das Framework der SAP ist noch nicht so weit um komplexes Coding zu unterstützen. Naja, zumindest, wenn die Zweifler doch nur richtige Entwickler wären und die notwendige Erfahrung hätten, dann würde sie ja auch nicht solche Fragen stellen. Oh Ego, kann man das auch bei Amazon bestellen?

Warum?

Wer jetzt denkt: wie kann man nur? Pech gehabt Tobias, aber das ist doch die absolute Ausnahme. Ich glaube nicht. Solches Coding ist auch 2026 nicht ausgestorben. Im Gegenteil: ich gehe mal davon aus das ein locker mittlerer 2-stelliger Prozentbereich des ABAP Codings bei Kunden so aussieht. Zumindest wenn der Kunde schon seit 20+ Jahren ABAP-Coding erstellt. Die Ein-Mann-Softwarefabrik bei Kunden ist auch keine Seltenheit. Und wenn im Endeffekt das Ganze mehr oder weniger läuft, auch wenn es keine Woche in 10+ Jahren gibt in denen kein Fehler gefunden und/oder Ticket aufgemacht wurde: es läuft halt doch gerade noch so gut das man keinen Sinn darin sieht es zu verbessern oder auszutauschen.

Andere Probleme sind dann wiederum die typischen Unternehmensregeln. Das jemand alleine jahrelang für eine Anwendung zuständig ist: das ist ein no-go. Das die Person keine Trainings besucht, sich nicht mit anderen Entwicklern im Unternehmen austauscht, sich abschottet und Falschinformationen über das Coding, die Nutzung und Use-Cases weitergibt: das geht natürlich gar nicht. Ja, menschlich und etwas verständlich ist es schon das man blockt und versucht seine Stellung zu retten. Aber hier schadet Ego, Überheblichkeit und Stolz das Unternehmen, die Mitarbeiter die den Prozess bedienen und generell die Reputation der involvierten Personen. Den Aufruf eines Reports in eine Methode zu kapseln und dies dann als OO zu bezeichnen: im besten (!!!) Falle hat hier jemand keine Ahnung was OO ist. Werte über Memory ID auszulesen: das ist mangelnde Professionalität auf mehreren Ebenen. Vor allem wenn man dann noch daran festhält. Bitte, Unternehmen und Manager: lasst es so weit mit den Menschen nicht kommen. Abwechslung tut gut. Neue Leute die sich einarbeiten sorgen auch dafür das die Doku halbwegs vorhanden und verständlich ist. Austausch zwischen Entwicklern ist nicht optional. Das ist Pflicht. Nur über den Austausch kann man lernen und die eigenen Fähigkeiten richtig einordnen und erweitern.