Code zuerst prüfen: So vermeidest du Fehler

• Lass danach die schnellen automatischen Checks laufen: Formatierung, Linter, Typprüfung, Build und passende Tests.
• Teste das geänderte Verhalten selbst. Ein grüner Check beweist nur, dass die eingerichteten Prüfungen bestanden wurden.
• Je höher das Risiko, desto tiefer die Kontrolle. Anmeldung, Rechte, Zahlungen, Datenlöschung, Schnittstellen und Abhängigkeiten brauchen mehr als einen schnellen Blick.
• Führe erst zusammen, wenn offene Fragen geklärt, wichtige Tests grün und ein Rückweg bekannt sind.

Eine geänderte Buttonfarbe und eine neue Berechtigungsregel dürfen nicht dieselbe Prüfrunde bekommen. Beim ersten Fall reichen oft Diff und Seitenansicht. Beim zweiten können falsche Rechte Daten fremder Nutzer öffnen. Die folgende Matrix hilft dir, die Prüftiefe am möglichen Schaden und am Rückweg auszurichten.

Was bedeutet „Code zuerst prüfen“?

Du arbeitest in einem eigenen Branch und öffnest anschließend einen Pull Request. Bei GitLab heißt derselbe Schritt Merge Request. Dort siehst du im Diff, welche Zeilen und Dateien sich gegenüber dem Ziel-Branch geändert haben. Der Pull Request bündelt außerdem Beschreibung, Kommentare und Ergebnisse automatischer Checks.

Ein Pull Request ist aber nur der Prüfplatz. Er prüft den Code nicht von selbst. Wenn kein Test eingerichtet ist, kann er auch nicht fehlschlagen. Wenn ein Test den falschen Fall abdeckt, kann er grün sein, obwohl Nutzer später ein Problem sehen.

Die einfache Reihenfolge lautet daher:

1. Änderung verstehen.
2. Diff auf Umfang und Versehen prüfen.
3. automatische Checks ausführen.
4. geändertes Verhalten testen.
5. Risiko und Sicherheit bewerten.
6. bei Bedarf einen zweiten Menschen hinzuziehen.
7. erst dann mergen.

Für wen passt dieser Ablauf?

Der Ablauf eignet sich für Solo-Entwickler, Agenturen, kleine Produktteams und Menschen, die KI-generierten Code übernehmen. Der Unterschied liegt nicht im Grundprinzip, sondern in der Tiefe:

• Solo: Der Pull Request schafft Abstand zur eigenen Arbeit. Warte nach Möglichkeit kurz, lies die Beschreibung neu und prüfe den Diff wie fremden Code.
• Kleines Team: Eine zweite Person kontrolliert vor allem Annahmen, Nebenwirkungen und Verständlichkeit.
• KI-unterstützte Entwicklung: Behandle erzeugten Code wie einen Vorschlag. Verstehe kritische Stellen, prüfe verwendete APIs und verlange passende Tests.
• Kunden- oder Produktivsystem: Plane zusätzlich Freigabe, Monitoring und Rückweg.

Wenn KI viel Code liefert und Tempo leicht mit Fortschritt verwechselt wird, hilft „KI-Tempo ist nicht Delivery“ dabei, Tests, Review und Verantwortung als eigene Lieferbedingungen festzulegen.

Code prüfen: der Ablauf in acht Schritten

1. Zweck in zwei Sätzen festhalten

Drei kurze Fragen geben dem Review eine klare Grenze:

• Welches Problem löst die Änderung?
• Woran erkennst du, dass sie funktioniert?
• Was soll ausdrücklich nicht verändert werden?

Ohne diese Grenze kannst du zwar sauberen Code sehen, aber nicht beurteilen, ob es der richtige Code ist. Eine gute Pull-Request-Beschreibung nennt deshalb Ausgangslage, gewünschtes Verhalten und Prüfschritte.

2. Den Diff vor dem ganzen Code lesen

Öffne zuerst die Dateiliste und überblicke den Umfang:

• Gehört jede Datei zum Ziel?
• Sind Debug-Ausgaben, Testschlüssel, lokale Konfigurationen oder große erzeugte Dateien hineingerutscht?
• Wurde neben der Funktion unbemerkt viel umformatiert oder umbenannt?
• Sind neue Bibliotheken oder Berechtigungen hinzugekommen?

Lies anschließend jede geänderte Zeile und bei kritischen Stellen auch den umliegenden Code. Nur der Diff kann Zusammenhänge verstecken. GitHub stellt dafür die geänderten Dateien und den Diff bereit; Googles Review-Leitfaden betont zusätzlich den Kontext des gesamten Systems.

Kleine, auf einen Zweck begrenzte Änderungen sind leichter gründlich zu prüfen. Eine pauschale Zeilengrenze gibt es trotzdem nicht. Ein automatisch erzeugter Datenblock kann groß und einfach sein; fünf Zeilen in einer Berechtigungsprüfung können klein und hochriskant sein.

3. Schnelle automatische Checks zuerst ausführen

Danach liefern die vorhandenen automatischen Werkzeuge schnelle Signale:

• Formatter oder Format-Check
• Linter
• Typprüfung
• Build
• Unit- und Integrationstests
• Sicherheits- oder Abhängigkeitsprüfung, wenn eingerichtet

Die konkreten Befehle stehen idealerweise im Repository-Handbuch oder in der CI-Konfiguration. Erfinde keine Befehle aus Gewohnheit: Ein JavaScript-Projekt kann npm, pnpm oder yarn verwenden; ein Python-Projekt ganz andere Werkzeuge.

Ein roter Check ist ein Stoppsignal. Ein grüner Check ist noch keine Freigabe. Er sagt nur: Die vorhandene Prüfung hat keinen bekannten Fehler gefunden.

4. Tests an der Änderung ausrichten

Ein guter Test belegt das gewünschte Verhalten und einen sinnvollen Fehlerfall. Wenn du eine Rechenregel änderst, teste normale Werte und Randwerte. Wenn du ein Formular änderst, prüfe gültige und ungültige Eingaben. Wenn du einen Fehler reparierst, sollte ein Regressionstest den alten Fehler ohne Fix wieder sichtbar machen.

Bei reiner Umstrukturierung soll das Verhalten gleich bleiben. Dann sind vorhandene Tests besonders wichtig. Gibt es für den kritischen Bereich gar keine Tests, ist das kein Grund, blind zu mergen. Es ist ein Risikohinweis: Ergänze einen gezielten Test oder erhöhe die manuelle Prüfung.

Für Tests mit Nutzerdaten solltest du keine echten Kundenkonten kopieren. Der Guide „Mit Testdaten sicher testen“ zeigt, wann synthetische, anonymisierte oder pseudonymisierte Daten passen.

5. Das Verhalten wie ein Nutzer prüfen

Nun zählt die Sicht des Nutzers. Öffne die betroffene Funktion in einer sicheren Testumgebung und probiere mehr als den glücklichen Weg:

• Funktioniert der normale Ablauf?
• Was passiert bei leerer, falscher oder sehr langer Eingabe?
• Bleibt eine verständliche Fehlermeldung?
• Funktionieren angrenzende Abläufe weiterhin?
• Sieht die Änderung auf kleinen und großen Bildschirmen sinnvoll aus, falls eine Oberfläche betroffen ist?
• Gehen Daten oder Zwischenschritte bei Abbruch verloren?

Bei APIs kontrollierst du neben der Erfolgsantwort mindestens ungültige Eingaben, fehlende Berechtigung und Fehlerverhalten. Eine verständliche Grundlage liefert „API einfach erklärt“.

6. Sicherheit dort vertiefen, wo Vertrauen wechselt

Ein normaler Code-Review und ein Sicherheitsreview sind nicht dasselbe. Prüfe besonders sorgfältig, wenn die Änderung Benutzereingaben, Anmeldung, Rollen, Zahlungen, Dateiuploads, Geheimnisse, Protokolle, externe APIs oder Datenlöschung berührt.

Automatische Scanner helfen bei bekannten Mustern. Sie verstehen aber nicht zuverlässig jede Geschäftsregel. Ein Mensch muss zum Beispiel fragen: „Darf dieser Nutzer genau diesen Datensatz ändern?“ OWASP beschreibt manuelle und automatische Prüfung deshalb als Ergänzungen.

7. Einen zweiten Blick nach Risiko wählen

Nicht jede Änderung braucht dieselbe Zahl von Freigaben. Bei Rechtschreibung oder internem Text kann Selbstprüfung genügen. Ein zweiter Mensch ist besonders wertvoll, wenn:

• Geld, personenbezogene Daten oder Zugriffsrechte betroffen sind,
• du den Bereich nicht gut kennst,
• eine neue Abhängigkeit oder Architekturentscheidung hinzukommt,
• die Änderung schwer zurückzunehmen ist,
• der Code unter Zeitdruck entstand,
• ein KI-Werkzeug einen großen Teil erzeugt hat.

Review heißt nicht, Geschmack durchzusetzen. Namen, Struktur und Kommentare sollen verständlich sein, doch persönliche Stilvorlieben dürfen wichtige Funktions- und Sicherheitsfragen nicht verdrängen.

8. Merge und Rückweg bewusst entscheiden

Merge erst, wenn Zweck und Umfang klar sind, erforderliche Checks grün sind, wichtige Review-Kommentare gelöst sind und die nötige Freigabe vorliegt. Geschützte Branches können solche Regeln technisch erzwingen, etwa Reviews oder Status-Checks vor dem Merge.

Frage bei riskanten Änderungen zusätzlich:

• Wie erkenne ich nach dem Deployment schnell ein Problem?
• Kann ich die Änderung zurückrollen oder per Feature-Schalter deaktivieren?
• Braucht die Datenbankänderung einen eigenen Rückweg?
• Wer beobachtet Fehler und wichtige Kennzahlen?

Der Prüfprozess endet also nicht am Merge-Knopf. Bei Produktivänderungen gehört eine kurze Kontrolle nach dem Deployment dazu.

Was automatische Checks nicht leisten

Automatisierung ist schnell und wiederholbar. Sie findet Syntaxprobleme, Typfehler, fehlgeschlagene Tests und manche bekannte Sicherheitsmuster. Sie kennt aber nicht automatisch die Absicht des Unternehmens.

Ein Beispiel: Ein Test kann korrekt bestätigen, dass ein Nutzer einen Datensatz löschen kann. Nur ein Mensch erkennt vielleicht, dass dieser Nutzer dazu gar nicht berechtigt sein sollte. Deshalb ist die beste Reihenfolge nicht „Mensch oder Maschine“, sondern:

1. Maschine findet schnelle, bekannte Fehler.
2. Entwickler prüft Verhalten und Kontext.
3. Reviewer konzentriert sich auf Risiko, Verständlichkeit und blinde Flecken.

Häufige Fehler beim Code-Review

Nur auf grüne CI warten

Grün bedeutet nicht fehlerfrei. Prüfe, welche Checks überhaupt gelaufen sind und welchen Bereich sie abdecken.

Eine riesige Änderung in einem Zug prüfen

Große Änderungen ermüden. Teile Funktionen, Refactorings und reine Formatierung möglichst auf. Google empfiehlt kleine, in sich geschlossene Änderungen und zugehörige Tests im selben Change.

Nur Zeilen lesen, nicht das Verhalten

Schöner Code kann die falsche Aufgabe lösen. Vergleiche Implementierung, Akzeptanzkriterium und sichtbares Ergebnis.

Sicherheitsfragen an einen Scanner abgeben

Scanner liefern Hinweise, keine vollständige Geschäftslogikprüfung. Berechtigungen, Datenwege und Missbrauchsfälle brauchen Kontext.

Unter Zeitdruck ganz auf Review verzichten

Ein echter Notfall kann einen schnellen Review rechtfertigen. Nach dem Fix sollte aber eine gründlichere Nachprüfung folgen. „Wir möchten heute noch veröffentlichen“ ist allein kein technischer Notfall.

Eine kurze Merge-Checkliste zum Kopieren

• Ziel und Nicht-Ziele sind verständlich.
• Jede geänderte Datei gehört zur Aufgabe.
• Keine Geheimnisse, Debug-Reste oder unbeabsichtigten Dateien im Diff.
• Formatierung, Linter, Typprüfung und Build sind – soweit vorhanden – erfolgreich.
• Passende Tests decken gewünschtes Verhalten und wichtige Fehlerfälle ab.
• Das Verhalten wurde in einer sicheren Umgebung geprüft.
• Rechte, Eingaben, Daten und neue Abhängigkeiten wurden risikogerecht betrachtet.
• Review-Kommentare und fehlgeschlagene Checks sind geklärt.
• Rückweg und Kontrolle nach dem Deployment sind bei riskanten Änderungen bekannt.

Häufige Fragen

Reicht ein Pull Request, wenn ich allein arbeite?

Ja, als fester Selbstkontrollpunkt. Er ersetzt keinen unabhängigen Blick, macht die Änderung aber sichtbar und nachvollziehbar. Bei hohem Risiko solltest du trotzdem eine zweite Person hinzuziehen.

Muss jede kleine Änderung getestet werden?

Jede Änderung sollte passend geprüft werden, aber nicht gleich aufwendig. Bei einem Textfehler können Diff und Seitenansicht reichen. Bei Logik, Daten oder Rechten sind gezielte automatische und manuelle Tests nötig.

Soll ich erst den Code lesen oder erst die Tests starten?

Beginne kurz mit Zweck und Umfang, dann starte die schnellen Checks. Während sie laufen, kannst du den Diff lesen. So verschwendest du keine tiefe Review-Zeit an eine Änderung, die bereits am Build scheitert.

Wie prüfe ich KI-generierten Code?

Verlange dieselben Belege wie bei menschlichem Code: verständlicher Zweck, kleiner Diff, passende Tests und nachvollziehbare APIs. Übernimm keine kritische Stelle, die niemand im Team erklären kann. Für einen kontrollierten Einsatz zeigt „Claude Code im Unternehmen“ einen passenden Pilotrahmen.

Wann ist der Code bereit zum Merge?

Wenn er das vereinbarte Problem löst, den Codezustand nicht verschlechtert, die risikogerechten Prüfungen bestanden hat und keine wichtige offene Frage übrig ist. Perfektion ist kein sinnvolles Ziel; ein bewusst begründeter, sicherer nächster Stand schon.

Fazit: Nicht länger prüfen, sondern passender

Ordne jede Änderung zuerst einer Risikostufe zu und arbeite dann die passenden Nachweise ab. Je größer der mögliche Schaden und je schwerer der Rückweg, desto unabhängiger und realistischer muss die Prüfung sein. Nach dem Merge kontrollierst du bei Produktivänderungen kurz, ob das erwartete Verhalten wirklich eingetreten ist.