Zustandslos im Montag

Montag, 06.05.19. Bielefeld.

Klarer Himmel, früher Morgen. Montage waren noch nie meine Stärke. Hier paaren sich unheilvoll spät ins Bett gehen vom Wochenende mit frühem Aufstehen in der Arbeitswoche und irgendwo lauert immer eine Überraschung. Und dieser Morgen überrascht mich nicht nur mit seiner Kälte.

Meine Winterjacke baumelt lustlos an meinen angewinkelten rechten Arm. Eigentlich hatte ich mich von ihr bereits vor Tagen, durch denen der Sommer hindurchlachte, verabschiedet. Sicherheitshalber nehme ich sie trotzdem mit. Und dort wärmt sie auch meinen Arm, während sich die Kälte an allen anderen Stellen rapide durch die dünnen Schichten Stoff frisst. Mein Anzug. Hemd. Unterhemd. Am Ende nur nackter Körper.

Der Weg zu meinem Auto ist glücklicherweise kurz und ich lege die Jacke mit der Innenseite auf dem Nebensitz ab, schalte dort die Sitzheizung an – bevor sie mich wärmen kann, muss sie selbst aufgeladen werden. Da der Wagen nicht wie eine Mikrowelle funktioniert, drücke ich auch den Knopf für meinen Sitz und fahre los.

Belohnung durch Arbeit

Aufsteigende Wärme aus dem Po-Bereich. Warum eigentlich erwärmen Sitzheizungen den Hinten stärker als den Rücken? Google weiß keine Antwort darauf – ok, ich gebe es zu, auch wenn man es kaum merkt: so wirklich ausgelastet bin ich momentan nicht. Da kommt man schon auf komische Gedanken, denn der Kopf kann nicht anders. Immerhin habe ich durch meinen Erfolg bei der Performance Optimierung (du erinnerst dich, die Pizza-Geschichte Teil I & Teil II) weitere Programme zur Analyse bekommen.

Quasi: Mit Ruhm bekleckert und Arbeit ausgezeichnet. Das kommt mir sehr gelegen. Momentan läuft das Kundenprojekt auf Sparflamme und es sind auch nur wenige Wochen, bis ich vom Berater auf die Kundenseite wechsle (ich habe nämlich gekündigt). Entspanntes Auslaufen des Projekts, doch ich würde gerne voll powern, sonst werde ich unruhig oder komme auf dumme Gedanken. Natürlich ist das nicht so schlecht, weil auch mein Kunde entspannt ist.

Hinter der Matrix

Also sitzen wir bei mir im »Büro Hakan«, so haben wir das Büro für Externe benannt, in dem ich ganz alleine wie ein Privatpatient sitze und schauen entspannt auf meinen Bildschirm. Wir gehen gemeinsam den Performance-Trace durch und es sieht nicht so aus, als könnte ich hier Wunder bewirken, als mir plötzlich etwas ganz Anderes auffällt.

Ich starre auf den Monitor. Konzentriert auf diesen einen Punkt. Wenn ich noch fokussierter wäre, könnte ich die einzelnen Pixel erkennen und vielleicht die Matrix dahinter.

»Was ist?«

»Siehst du diesen Aufruf hier?« Ich zeige langsam mit dem Finger auf eine Codingstelle und drehe mich dann zu ihm um.

Er beugt sich ein wenig vor, als würde er es dann besser verstehen, wenn er es besser sehen könnte. Das ist wie die Illusion des Ampel-Drückens am Straßenrand.

»Ja.«

Ich gehe davon aus, dass sein Ja dem Sehen gilt. Hätte ich selbst nicht an dem Thema gearbeitet, wäre es mir auch nicht aufgefallen.

»Die Art, wie sie hier die einzelnen Funktionen mit Parametern aufrufen, zeigt, dass sie die Prozessschritte in zustandslose Aufrufe zerlegt haben.«

»Ok.«

Das klingt nicht so überzeugend.

»Der Prozess besteht aus Schritt A gefolgt von Schritt B. Wenn du Schritt B aufrufst, dann benutzt du die Daten vom vorherigen Schritt A. Um das zu können, muss du an diese Daten herankommen. Wenn du in einer Session beide Schritte aufrufst, ist das kein Problem.«

»Ok.«

Da ist es wieder. Diesmal klingt es so, als sollte ich auf den Punkt kommen.

»Die haben die Funktionen aber so umgesetzt, dass man Schritt B in einer anderen Session von Schritt A ausführen kann. Im Prinzip meldest du dich nach Schritt A ab und meldest dich für Schritt B neu an. Damit kannst du auf die Daten aus Schritt A nicht in der Session zugreifen und musst an sie herankommen und an B übergeben. Und das tun sie.«

Klingt banal, ist aber in der Praxis nicht immer einfach. Denn die nötigen Daten verstecken sich manchmal in tieferen nicht zugänglichen Schichten. Gelangt man in diese Daten, bedeutet das auch nicht zwangsläufig, dass man die Daten ohne Weiteres an den Prozessschritt B weitergeben bzw. diese an der Übergabestelle aufnehmen und weiterverarbeiten kann.

Er schaut so, als würde er weder einen Tunnel noch einen Bahnhof erkennen.

»Das ist vorteilhaft für Schnittstellen, die beispielweise von Webseiten oder anderen externen System aufgerufen werden und nennt sich zustandslos (stateless).«

Pause. Blickaustausch.

Das Problem mit dem bereits gelösten Problem

»Das war genau das ausufernde Problem, dass andere Kollegen mit der Anbindung an ihre externe Software hatten, weil sie die Verbindung übers Internet mit dem Backend während der Prozessschritte A und B halten mussten. An der Lösung saßen sie Legende zufolge über ein Jahr und ich durfte ihre Stateful-Version in wenigen Tagen in eine stateless umbaue. Das heißt«, ich mache diesmal eine bedeutungsvolle Pause, denn schon damals, als mir die Aufgabe übertragen wurde, verstand ich nicht, warum man an einer stateful Lösung arbeitete statt an einer stateless, »es gab bereits eine funktionierende Lösung, von der die Kollegen nichts wussten.«

So viel Zeit, Aufwand und Kosten wurden investiert, ging mir sofort durch den Kopf. Und wenn mir etwas durch den Kopf geht, zieht es ein wenig darin umher und wirbelt andere Dinge auf. Unterschiedliche Menschen mit unterschiedlichen Motivationen liefern unterschiedliche Ergebnisse mit unterschiedlicher Qualität. Bei Software mag das vielleicht nicht so schlimm sein wie bei Berufen, die sich auf andere Menschen auswirken wie bei Ärzten, Anwälten, Ermittlern etc. Die Vorstellung gefällt mir gar nicht.

Ich nicke ihm zu und schiebe ein: »Das hat jetzt nichts mit unserer Performance-Analyse zu tun.«

»Ach so.«

Die Schuldfrage

Ich habe schon sehr viele ABAP Programme auf SAP Systemen analysiert und sogar optimiert. Irgendwann, wenn ich meine Analyse abgeschlossen habe und unerwartet gut optimiere, kommt immer, mal offen, mal verdeckt, die Frage, warum ich es optimieren konnte und nicht der ursprüngliche Programmierer.

Hinter dieser Frage versteckt sich die Suche nach dem Schuldigen. Daher mag ich sie nicht. Man muss die Umstände kennen, unter der diese Lösung umgesetzt wurde.

Manchmal sind es Programme, die irgendjemand mal irgendwann umgesetzt hatte und vergessen wurden, bis es zu Performance-Problemen kam. Diese Probleme entstehen mit der Zeit, weil die Datenmengen wachsen.

Manchmal sind die Programme über die Jahre gewachsen, üppig und nicht ganz gutartig. Statt das Programm komplett zu überarbeiten, hängen einige die Zusatzfunktion einfach ans Ende des Programms. Gründe hierfür gibt es viele. Man will den bereits funktionierenden und getesteten Teil nicht verändern.

Häufig dürfen auch mal zu verschiedenen Zeiten verschiedene Menschen an einem Programm arbeiten.

Für alle gilt meistens: Zeit und Budget spielen eine große Rolle. Unter Zeitdruck und mit knappem Budget muss man Kompromisse schließen.

Dann bleibt auch keine Zeit, nach bereits bestehenden Lösungen zu suchen, die wiederverwendet werden kann. Manchmal wende ich für diese Suche, begleitet von Nachfragen bei dem jeweiligen Autor, mehr Zeit auf, als für die Programmierung selbst. Ob man etwas findet, hängt neben Erfahrung und (viel) Geduld auch von Glück ab. Und wenn man Pech hat, sitzt man an einer eigenen Lösung für die es bereits eine Lösung gibt. Manchmal sogar eine bessere.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.