© Ekaphon maneechot/Shutterstock.com
Verbessern - aber richtig!

Gegen die dunkle Macht


Ein ganz normaler Tag: Morgens frage ich mich, welche Katastrophe mich heute erwartet. Ich bin einiges gewohnt, aber die letzten Monate wurde es immer schlimmer: Früher gab es nur Fehler im Test oder Schwierigkeiten bei der Entwicklung. Jetzt kommen auch noch Laufzeitfehler dazu, die den Betrieb im Rechenzentrum stören und unsere Endkunden massiv irritieren. Als hätte sich die dunkle Macht gegen uns verschworen – dabei haben wir doch nur ganz normale Anforderungen. Aber sicherlich das schlechteste Software­system der Welt ...

Ein frei erfundenes Unternehmen mit einer ganz typischen Software – über lange Jahre ständig weiterentwickelt, in der Regel unter Zeit- und Budgetdruck. Ein kleiner, aber fachlich komplexer Produktkatalog, ein großer Bestand von Endkunden, deren Bestellungen und Rechnungen wir in unserem System verarbeiten und anzeigen müssen. Ein bisschen Java, etwas relationale Datenbank, eine Portion SQL. Die ein oder andere kleine Sünde im System, nichts Besonderes – dachte ich immer.

Aber mal von Anfang an: Vor drei Jahren bin ich als Neuzugang zu unserem Team gestoßen. Vorher hatte ich einige Jahre Webshops und Java-Backends für eine kleine Firma gebaut, dann bin ich zu diesem großen und seriösen Unternehmen gewechselt und durfte direkt am Kernsystem mitarbeiten.

Mit was für schicken Sachen haben die damals um sich geworfen: Scrum und Kanban, polyglotte Entwicklung, attraktive Technologie und unternehmenskritische Anwendung. Alles wahr, aber einige Details habe ich erst später leidvoll erfahren müssen. Ich versuche mal eine Kurzbeschreibung: Eigentlich sollte das System drei Schichten haben ...

Datenchaos

Aber schon unsere Datenhaltung nervt: Die meisten Daten liegen in ca. dreißig Tabellen in einer relationalen Datenbank. Leider haben wir vor zehn Jahren eine Firma übernommen, deren Datenbestand von einer AS/400 stammt: Die hatten sämtliche Stamm- und Produktionsdaten in einer netzartigen Struktur abgebildet: fünf Tabellen mit jeweils 400 Spalten, massiv über Kreuz vernetzt. Wir wollten das immer mal auf unser Datenmodell migrieren, hatten bisher aber keine Zeit dazu.

Die Daten von den fast 300 000 Altkunden müssen wir über den Umweg dieser grausamen Struktur lesen und schreiben. Bei jedem Zugriff auf Kundendaten müssen wir jetzt differenzieren, ob der Kunde im alten oder neuen Bestand liegt – und mit jeweils anderer Zugriffslogik bearbeiten. Welche Kunden wo liegen, entscheidet übrigens eine eigene Konfig-Tabelle in der neuen Datenbank (Abb. 1).

starke_improve_1.tif_fmt1.jpgAbb. 1: Datenchaos (rot: schlimmes Problem)

Und dann war da noch das optische Archiv, in das sich – leider fehlerhafte – Dokumente eingeschlichen haben, die man aber nicht mehr löschen kann oder darf. Das Altsystem liest Teile seiner Daten aus diesem Archiv, und muss dann jeweils in einer Blacklist-Tabelle nachprüfen, ob diese speziellen Datensätze bekannte Fehler enthalten – welch ein unglaublicher Mist.

Von wegen Businesslogik

Einige Teile unserer Businesslogik stecken brav in einem einzigen Package, lauter POJOs mit Spring, übersichtlich und gut verständlich. Leider liegen die meisten Geschäftsregeln und -services nahezu beliebig verstreut in alten Systemteilen, manche davon in Perl, C, C++ oder sogar XSLT geschrieben (wobei „verbrochen“ der treffende Begriff wäre).

Es verfault von innen

Eine Kernaufgabe unseres Systems ist die Ermittlung von Preisen für Angebote und Waren. Stellen Sie sich vereinfacht vor, Kunden haben einen komplexen Warenkorb, mit aufwändig konfigurierten Produkten drin. Unsere Pricing Engine prüft nun Firmen- und Einzelrabatte, Sondervereinbarungen, Mindest- und Höchstmengen, Sonderregelungen für Produktkombinationen und allerhand weitere Bedingungen, um daraus einen Gesamtpreis zu berechnen. Das hat vor langer Zeit ein hoch motivierter (Ex-)Mitarbeiter in Haskell implementiert – rein funktional, zustandslos und recht performant, damals zumindest. Der Kollege hat vor zwei Jahren unsere Firma verlassen – und kein anderer hat bisher den dafür nötigen Haskell-Guru-Status erreicht: Wir verstehen seinen Code in großen Teilen nicht. Funktoren, Monaden und teilweise 10- bis 15-fach geschachtelte Funktionsaufrufe ... Insgesamt mehr als 20 000 Zeilen, die jeden aufsaugen, der zu lange im Editor draufschaut. Niemand traut sich wirklich, darin etwas zu ändern, Tests sind aufgrund der ständig wechselnden Preis- und Rabattmodelle total schwierig zu bauen – und „neu schreiben“ hat uns das Management verboten. Ein e...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang