„Am Ende versteht unser Team den Code nicht" - wie wir das verhindern

Executive Summary

„Der Code gehört euch" klingt nach Sicherheit. Aber Eigentum allein ist wertlos, wenn niemand mit dem Code umgehen kann. Genau hier scheitern viele E-Commerce-Projekte: Der Shop läuft, der Dienstleister ist weg - und das eigene Team steht vor einer Black Box, die niemand anfassen will. Wir verhindern das nicht durch ein nettes Übergabedokument am Schluss, sondern durch Standards ab Tag 1: sauberer Code, Tests, Dokumentation und automatische Pipelines, die Fehler auch dann abfangen, wenn jemand weniger Erfahrenes am Code arbeitet. Dieser Beitrag erklärt, wie wartbarer Code entsteht und warum unsere Übergabe-Philosophie der eigentliche Kern ist.

Warum „der Code gehört euch" allein nichts wert ist

In Teil 1 dieser Serie haben wir es bereits angesprochen: Bei uns bleibt der Code beim Kunden. Das ist die Grundlage von Unabhängigkeit - aber es ist eben nur die Grundlage.

Eigentum am Code nützt euch nur, wenn jemand damit arbeiten kann. Wenn euer internes Team oder ein neuer Entwickler den Shop nicht ohne wochenlange Archäologie versteht, dann besitzt ihr formal etwas, mit dem ihr praktisch nicht handlungsfähig seid. Ihr seid weiter abhängig - nur jetzt von jemandem, der bereit ist, sich in fremden, schlecht dokumentierten Code einzuarbeiten. Das ist teuer und selten.

Wartbarkeit ist deshalb keine Kür am Projektende. Sie ist eine Eigenschaft, die von der ersten Zeile an mitgebaut wird - oder eben nicht.

Hohe Standards ab Tag 1

Wartbarer Code lässt sich nicht nachträglich aufpolieren. Wer drei Monate schnell und unsauber baut, kann das nicht in der letzten Woche reparieren. Deshalb gelten unsere Standards vom ersten Tag an:

• Clean Code. Verständliche Namen, klare Struktur, nachvollziehbare Logik. Code wird viel öfter gelesen als geschrieben - wir schreiben ihn für die Person, die ihn in einem Jahr anfassen muss.

• Dokumentation. Nicht jede Zeile, aber die Entscheidungen, die nicht selbsterklärend sind: Warum ist etwas so gebaut, wo hängt es mit anderen Teilen zusammen.

• Tests. Sie beschreiben, was der Code leisten soll, und schlagen Alarm, wenn eine spätere Änderung etwas kaputt macht.

• Automatische Pipelines. Sie prüfen jede Änderung, bevor sie live geht - auch dann, wenn die Person dahinter weniger Erfahrung hat.

Der letzte Punkt ist für euch besonders wichtig: Gute Pipelines senken die Hürde, überhaupt etwas am Shop zu ändern. Euer Team muss nicht jede Konsequenz im Kopf durchrechnen - das Sicherheitsnetz fängt typische Fehler ab.

Was die DevOps-Pipeline konkret macht

„Pipeline" klingt technisch, die Idee dahinter ist einfach: Bevor eine Änderung im echten Shop landet, läuft sie automatisch durch mehrere Prüfungen.

• Linting prüft, ob der Code grundsätzlich sauber und einheitlich geschrieben ist - eine automatische Qualitätskontrolle für die Form.

• Unit-Tests prüfen einzelne Bausteine isoliert: Tut dieser eine Teil das, was er soll?

• Integration-Tests prüfen das Zusammenspiel: Funktioniert der Bestellprozess auch dann noch, wenn mehrere Teile zusammenarbeiten?

Findet eine dieser Prüfungen ein Problem, geht die Änderung gar nicht erst live. Der Fehler wird abgefangen, bevor ein Kunde ihn merkt.

Im laufenden Betrieb kommt eine zweite Ebene dazu. Werkzeuge zur Analyse und Fehlererkennung - etwa Elastic APM für Performance und Sentry für Fehlermeldungen - zeigen, wenn im echten Einsatz etwas hakt. So wird ein Problem sichtbar, solange es noch klein ist, statt erst über eine Beschwerde-Mail.

Unsere Übergabe-Philosophie

Hinter all dem steht ein einfacher Maßstab, der unsere Arbeit prägt:

Wir übergeben einen Shop so, wie wir ihn unserem eigenen nächsten Mitarbeitenden geben würden.

Das ist kein Slogan, sondern ein konkreter Test. Ein neuer Kollege bei uns würde keinen undokumentierten Code akzeptieren, kein Projekt ohne Tests, keine Einrichtung, die nur eine einzige Person im Kopf hat. Genau diesen Anspruch legen wir an das an, was bei euch landet.

Der Grund ist nüchtern: Wenn ihr den Shop nach der Übergabe nicht mehr bedienen oder weiterentwickeln könnt, haben wir keinen Wert geschaffen - wir haben eher Wert zerstört. Ein Shop, den nur der ursprüngliche Dienstleister versteht, ist eine neue Abhängigkeit, kein Vermögenswert.

KI nimmt viel ab - aber nicht das Verständnis

KI gehört heute fest zu unserer Arbeit und übernimmt beim Programmieren einen großen Teil - als grobe Faustregel, nicht als gemessener Wert. Das beschleunigt vieles.

Aber der Rest ist genau der Teil, auf den es ankommt: die richtige Architektur, die Einschätzung, wo eine Abkürzung später teuer wird, das saubere Handwerk. Tests und Pipelines fangen viele Fehler ab - sie ersetzen aber nicht das Verständnis dafür, ob etwas grundsätzlich richtig gebaut ist. Genau deshalb sitzt bei uns ein erfahrener Engineer am Code, kein Werkzeug allein. Wie KI sinnvoll im Shop selbst zum Einsatz kommt, etwa über unsere Plattform BaseGPT, ist Thema eines späteren Beitrags dieser Serie.

Fazit

Wartbarer Code ist kein technisches Detail, das euch als Entscheider nicht zu kümmern braucht - er entscheidet, ob euer Shop ein Vermögenswert ist oder eine versteckte Abhängigkeit. Clean Code, Tests, Dokumentation und Pipelines ab Tag 1 sorgen dafür, dass euer Team handlungsfähig bleibt, auch wenn wir nicht mehr im Projekt sind. Das ist für uns kein Zusatz, sondern die Definition einer Übergabe, die diesen Namen verdient.

Teil 3 der Serie „E-Commerce ohne Bullshit".