Preislogik konsolidiert

Von zwölf Skripten zu einem Modul – abgesichert durch Tests, eingeführt im laufenden Betrieb.

Preislogik konsolidiert

Ausgangslage

Über die Jahre war die Preislogik für mehrere Shops in getrennten Skripten gewachsen. Viele Regeln ähnelten sich, unterschieden sich aber im Detail. Wer etwas ändern wollte, musste an mehreren Stellen drehen – mit dem Gefühl, stets eine Abzweigung zu übersehen. Tests gab es nur punktuell.

Das Problem war weniger „komplexe Preise“ als „komplexe Verteilung“: Wissen steckte im Code an mehreren Orten. Genau das wollten wir entkoppeln und unter Kontrolle bringen.

Zielbild & Anforderungen

Das Ziel war nicht „neue Preise“, sondern eine neue Form von Kontrolle: weniger Duplikate, weniger Stellen zum Übersehen, bessere Nachvollziehbarkeit im Alltag.

  • Eine zentrale Preislogik als wiederverwendbares Modul statt verteilter Skripte
  • Konfiguration statt Code-Forks: Regeln sollen versionierbar und reviewbar sein
  • Sichere Einführung im laufenden Betrieb, mit klarer Rückfalloption
  • Gleiche Ergebnisse wie zuvor: fachlich identische Preise, aber nachvollziehbarer

Rahmenbedingungen: laufender Betrieb ohne Downtime, mehrere Shops/Varianten, historisch gewachsene Regeln, minimale Eingriffe in angrenzende Systeme.

Lösungsweg

Wir sind bewusst schrittweise vorgegangen: erst fachliche Klarheit und Tests, dann eine stabile Modul-Schnittstelle, danach die Umstellung pro Shop. So blieb das Risiko beherrschbar, obwohl die Logik tief im Tagesgeschäft hängt.

  1. Bestehende Varianten der Preislogik als Black-Box erfassen und in Testfälle überführen
  2. Gemeinsame Regeln identifizieren und in eine eindeutige Modul-Schnittstelle überführen
  3. Sonderfälle über Konfiguration abbilden, ohne Code-Forks zu erzeugen
  4. Shadow-Run im Parallelbetrieb: Alt/Neu vergleichen, Abweichungen gezielt schließen
  5. Umschaltung je Shop mit Rückfalloption und sauberem Rollout-Prozess

Umsetzung

Die Umsetzung war weniger ein „Rewrite“, sondern eine kontrollierte Konsolidierung: aus vielen ähnlichen Implementierungen wurde ein einziges, klar abgrenzbares Modul.

Der erste Schritt war, das bestehende Verhalten festzuhalten, bevor wir es anfassen: Black-box-Tests für die kritischen Pfade, bis die Vielfalt der Fälle abgedeckt war. Danach ließ sich eine öffentliche Schnittstelle definieren, die das Wesentliche ausdrückt: Eingaben klar benannt, Ausgaben eindeutig, keine Seiteneffekte. Auf dieser Basis entstand ein Modul, das die Regeln zentral bündelt; Unterschiede zwischen Shops wandern in Konfigurationsdateien statt in neue Code-Forks.

Konkret (vereinfacht)
# defaults.yaml
price_rules:
  rounding: bankers
  vat: 19
  promo:
    allow_stacking: false

# shop-fr.yaml (nur Abweichungen)
vat: 20
promo:
  allow_stacking: true

Ergebnis / Impact

  • Preislogik konsolidiert: zwölf Skripte in ein Modul überführt
  • Änderungen an Regeln sind heute schneller reviewbar und deutlich weniger fehleranfällig
  • Einführung ohne Big-Bang: Shadow-Run und schrittweise Umschaltung pro Shop

Validierung über umfangreiche Black-Box Tests und Shadow-Run-Vergleiche (Altlogik vs. Modul) im laufenden Betrieb.

Validierung & Qualität

Bei Preislogik ist „funktioniert meistens“ keine Option. Entscheidend war deshalb ein Sicherheitsnetz, das nicht von implizitem Wissen abhängt, sondern reproduzierbar ist.

Die Tests sind das Sicherheitsnetz – über zweihundert Fälle, die die vorherigen Varianten abdecken. Für die tägliche Arbeit heißt das: Code-Reviews konzentrieren sich auf Regeln, nicht auf Dateisuche. Eingeführt wurde das Modul schrittweise: zunächst als Shadow-Run, dessen Ergebnisse wir mit der Altlogik verglichen haben; danach die Umschaltung je Shop, mit Rückfalloption im Rücken.

Zusätzlich haben wir die Schnittstelle so gestaltet, dass Seiteneffekte ausgeschlossen sind. Das macht Abweichungen sichtbar und behebt sie dort, wo sie entstehen: in Regeln und Daten, nicht in Copy/Paste-Varianten.

Betrieb & Rollout

Der Rollout wurde so gestaltet, dass er operativ jederzeit stoppbar bleibt. Im Alltag ist das der Unterschied zwischen „wir hoffen“ und „wir steuern“.

Nach dem Shadow-Run erfolgte die Umschaltung je Shop. Für jede Umstellung gab es einen klaren Umschaltpunkt, Monitoring auf die relevanten Preis-Signale und eine Rückfalloption, falls ein Randfall im echten Traffic auftaucht.

Was heute anders ist

Die Preislogik liegt an einem Ort und ist über eine stabile API greifbar. Neue Anforderungen lassen sich als Konfiguration ergänzen, ohne Kopien anzulegen. Änderungen bleiben nachvollziehbar – in Tests, im Review und im Betrieb.

Kurzinfo

Dauer

ca. 6 Wochen (inkl. Tests & Rollout)

Rolle

Backend/Refactoring, enge Abstimmung mit Fachseite

Werkzeuge

Perl 5, Test::More, Devel::Cover, YAML::XS, Git (CI)