--- title: "„Am Ende versteht unser Team den Code nicht\" - wie wir das verhindern" url: https://coding9.de/blog/wartbarer-code-und-uebergabe author: "Felix Astner" datePublished: 2026-05-21T00:00:00.000Z dateModified: 2026-05-21T00:00:00.000Z description: "„Der Code gehört Ihnen\" ist nur etwas wert, wenn Ihr Team damit umgehen kann. Warum wir ab Tag 1 auf Clean Code, Tests und Pipelines setzen." --- # „Am Ende versteht unser Team den Code nicht" - wie wir das verhindern ## Executive Summary „Der Code gehört Ihnen" 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 mit Standards ab Tag 1 statt mit einem Übergabedokument am Schluss: Clean 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 woran wir eine Übergabe messen. ## Warum „der Code gehört Ihnen" 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 Ihnen nur, wenn jemand damit arbeiten kann. Wenn Ihr internes Team oder ein neuer Entwickler den Shop nicht ohne wochenlange Archäologie versteht, dann besitzen Sie formal etwas, mit dem Sie praktisch nicht handlungsfähig sind. Sie sind weiter abhängig - nur jetzt von jemandem, der bereit ist, sich in fremden, schlecht dokumentierten Code einzuarbeiten. Das ist teuer und selten. **Wartbarkeit entsteht ab der ersten Zeile Code. Wer sie am Projektende nachrüsten will, bezahlt ein Refactoring statt einer Übergabe.** ## 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 Sie besonders wichtig: Gute Pipelines senken die Hürde, überhaupt etwas am Shop zu ändern. Ihr 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.** Daraus folgt ein prüfbarer Maßstab. Ein neuer Kollege bei uns würde undokumentierten Code zurückgeben, ein Projekt ohne Tests ebenso und eine Einrichtung, die nur eine einzige Person im Kopf hat, erst recht. Genau diesen Anspruch legen wir an das an, was bei Ihnen landet. Der Grund ist nüchtern: Wenn Sie den Shop nach der Übergabe nicht mehr bedienen oder weiterentwickeln können, 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. ## Was das für Sie als Entscheider heißt Wartbarer Code entscheidet, ob Ihr Shop ein Vermögenswert ist oder eine versteckte Abhängigkeit - das macht ihn zur Entscheider- und nicht zur Entwicklerfrage. Clean Code, Tests, Dokumentation und Pipelines ab Tag 1 sorgen dafür, dass Ihr Team handlungsfähig bleibt, auch wenn wir nicht mehr im Projekt sind. Genau daran messen wir, ob eine Übergabe diesen Namen verdient. *Teil 3 der Serie „E-Commerce ohne Bullshit".* --- Quelle: [„Am Ende versteht unser Team den Code nicht" - wie wir das verhindern](https://coding9.de/blog/wartbarer-code-und-uebergabe)