Einmal alles neu: Version 3 des Klick & Bügelstudios

Ein Produkt, zwei Folien, null Lösung

Im letzten Beitrag hatte ich erzählt, wie unser BFF-Set mit dem geteilten Herz die komplette Blueprint-Logik gesprengt hat. Ein Produkt, zwei Folien, zwei separate Bügelbilder. Das passte einfach nicht in die Architektur von Version 2.

Ich hätte das irgendwie reinflicken können. Einen Sonderfall einbauen, eine Ausnahme programmieren. Viele Entwickler würden genau das tun. Aber ich wusste: Das BFF-Set war nur der Anfang. Ich hatte noch andere Ideen auf der Liste. Einen Layout-Editor, dynamische Mockups, eine vereinfachte Render-Pipeline. All das hätte ich in V2 reinquetschen müssen wie einen Elefanten in einen Kleinwagen.

Also hab ich eine Entscheidung getroffen, die sich erstmal dumm anhört: Alles wegschmeißen. Komplett. Und Version 3 von Grund auf neu bauen.

Gartenhaus oder Villa: Warum Abreißen manchmal schneller ist

Ich weiß, das klingt verrückt. Warum wirft man funktionierenden Code weg? Aus meiner langjährigen Erfahrung als Leiter einer Software-Abteilung kann ich dir sagen: Das ist oft die schnellste Art, vorwärtszukommen.

Die meisten Leute denken wie beim Hausbau. Ein ganzes Haus abreißen und neu bauen ist teurer als sanieren. Das stimmt auch meistens. Bei Häusern. Aber stell dir vor, du hast ein Gartenhaus. Klein, gemütlich, reicht für die Gartengeräte. Jetzt merkst du: Eigentlich brauche ich eine Villa. Mit zwei Etagen, Dachziegeln, Keller.

Warum sollte ich mich an die Regeln des Gartenhauses halten? Es fängt schon beim Fundament an. Ein Gartenhaus steht auf einer Betonplatte. Eine Villa braucht ein ordentliches Fundament. Die Traglast des Gartenhauses reicht nicht für eine zweite Etage. Das Dach ist nicht für Ziegel ausgelegt. Du kannst renovieren so viel du willst. Am Ende hast du ein schiefes Gartenhaus mit angeklebter zweiter Etage.

In der Software-Entwicklung ist es genauso. Wenn die Grundstruktur nicht zum neuen Ziel passt, ist Neubauen effizienter als Flicken. Punkt.

Der Campingplatz in meiner Software

Für Version 3 habe ich die Architektur komplett umgedacht. Statt einem großen Programm, das alles macht, habe ich auf Micro-Services gesetzt. Falls dir das nichts sagt, stell dir einen Campingplatz vor.

Ein Campingplatz hat viele Parzellen. Auf jeder steht ein Mobile Home. Alle sind über die Wege miteinander verbunden. Das ist die Infrastruktur. Einfach, übersichtlich, leicht zu pflegen. Einmal am Tag kommt der Gärtner vorbei, der Rest läuft von alleine.

Die Mobile Homes sind die einzelnen Services. Wie sie innen aussehen, kann jeder selbst entscheiden. Einer hat ein großes Wohnzimmer, der andere eine Werkstatt. Aber alle haben einen Eingang. Das ist der Endpunkt, über den die anderen Services wissen: Da wohnt der Dirk, da kann ich anklopfen.

Und jetzt kommt der Clou: Wenn ich ein Mobile Home abreiße und neu baue, ist das super effizient. Denn es bleibt meine Parzelle. Der Eingang ist an der gleichen Stelle. Wenn jemand zu mir möchte, findet er mich dort, wo er mich immer findet. Dass mein Wohnzimmer jetzt größer und heller ist, interessiert die anderen nicht wirklich.

So ist es in der Entwicklung auch. Wie ein Service intern funktioniert, geht die anderen nichts an. Wichtig ist nur: Welche Daten übergebe ich? Was bekomme ich zurück? Mega einfach, oder?

Der Layout-Editor, den Katrin sich gewünscht hat

Ein wichtiges Ziel für V3: Katrin muss in der Lage sein, eigene Layouts zu erstellen. Ohne mich. Denn bisher war es so: Katrin hatte eine Idee für ein neues Produkt, ich musste es programmieren. Jedes Mal. Das ist auf Dauer kein haltbarer Zustand.

Also habe ich einen Online-Editor geschrieben. Im Editor kann Katrin drei Dinge anlegen: Text, Bilder und Rechtecke. Warum Rechtecke? Ganz einfach. Ein Rechteck ist ein Platzhalter. Es nimmt Platz auf dem Layout ein. Wenn der Kunde später ein Bild hochlädt, wird das Rechteck durch das Bild ersetzt. So muss ich nicht schon im Layout ein Bild haben, das die Datei nur unnötig aufbläht.

Wie es so mit Editoren ist: Sie wachsen. Mittlerweile hat der Layout-Editor vier verschiedene Ansichten. Die Layout-Ansicht, in der gestaltet wird. Die Vorschau, in der das Formular getestet werden kann. Die XML-Ansicht, in der ich das Layout direkt im Code bearbeiten kann. Und die Mapping-Ansicht, die mir zeigt, welche Layout-Elemente mit welchen Formular-Elementen verbunden sind.

Mockups: Damit du siehst, wie es wirklich aussieht

Aber ein Editor war mir für V3 noch nicht genug. Ich habe einen zweiten gebaut. Einen Mockup-Editor. Der Gedanke dahinter: Wenn du ein Bügelbild bestellst, willst du sehen, wie es auf einem Shirt aussieht. Nicht nur das Motiv auf einem weißen oder karierten Hintergrund, sondern auf einem echten T-Shirt. Oder einem Kissen. Oder einer Tasche.

Im Mockup-Editor können wir dynamisch Vorschauen erstellen. Der Standard ist der karierte Hintergrund, damit du siehst, was transparent ist. Aber wir können auch Fotos von Produkten hinterlegen. Ein graues T-Shirt, ein schwarzes Kissen, was auch immer. Natürlich kann eine Folie auch mehrere Vorschauen haben. Vorne auf dem Shirt, hinten auf dem Shirt, auf dem Ärmel.

Vier Renderer? Jetzt nur noch einer

Erinnerst du dich an die zwei Renderer aus V2? Der eine für den Shop, der andere fürs Backend? In V3 waren es irgendwann vier geworden. Shop-Vorschau, Backend-Druck, Mockup-Vorschau, Editor-Vorschau. Die alle synchron zu halten war ein Krampf. Wenn ich an einer Stelle etwas geändert habe, musste ich prüfen, ob es an den anderen drei auch noch stimmt.

Also hab ich auch hier aufgeräumt. Vier Renderer raus, ein Renderer rein. Einer für alles. Gleiche Engine, verschiedene Ausgabeformate. Ob niedrig aufgelöst für den Shop oder hochauflösend für den Druck: Der Renderer ist derselbe. Er bekommt nur andere Parameter.

Das war einer der größten Gewinne von V3. Weniger Code, weniger Fehlerquellen, weniger Wartung. Manchmal ist weniger wirklich mehr.

Von 3.1 bis 3.3: Es geht immer weiter

Ich geb zu: Auch in V3 habe ich nicht alles beim ersten Mal richtig gemacht. Es gab drei weitere Iterationen. V3.1, V3.2, V3.3. Ja, ich habe es tatsächlich dreimal neu gebaut. Innerhalb von V3. Aber keine V4, V5, V6. Denn in meinem Kopf ist V4 nochmal was ganz anderes. Dazu vielleicht Ende des Jahres mehr, wenn ich soweit bin 😉

Jede Iteration hat das System besser gemacht. Stabiler, schneller, flexibler. V3 kann jetzt mehrere Folien pro Produkt verarbeiten. Das BFF-Set? Kein Problem mehr. Katrin kann eigene Layouts bauen. Die Mockup-Vorschauen sehen richtig gut aus. Die Render-Pipeline ist aufgeräumt.

Und das Schöne ist: Dank der Micro-Service-Architektur kann ich einzelne Teile austauschen, ohne dass der Rest davon betroffen ist. Genau wie auf dem Campingplatz. Ein Mobile Home wird renoviert, die Nachbarn merken nichts davon.

Was als Nächstes kommt

In den nächsten Wochen kommen weitere Updates zum Klick & Bügelstudio. Es ist eine Baustelle, die nie fertig wird. Aber das ist bei Software so. Es gibt immer etwas zu verbessern, immer eine neue Idee, immer ein Kundenwunsch, der noch nicht abgedeckt ist.

Was mich antreibt: Jede Verbesserung macht es für dich als Kunde einfacher, dein perfektes Bügelbild zu gestalten. Weniger Klicks, bessere Vorschauen, mehr Möglichkeiten. Das ist das Ziel. Darauf arbeite ich hin.