Wenn die KI Ihre React-App schreibt, aber die Prinzipien des sauberen Codes ignoriert
Erlernen Sie sieben Gewohnheiten sauberen Codes – DRY, einzige Verantwortung, Schutzklauseln und mehr – die in von KI erzeugtem React-Code oft verletzt werden und wie man sie behebt.
Ein Kunde hat kürzlich ein Projekt abgegeben, bei dem es um den Aufbau einer Website zum Bestellen von Pizza ging.
Zu Beginn schien der Umfang handhabbar zu sein.
Eine Landing Page.
Ein Menüabschnitt.
Unterschiedliche Pizza-Kategorien.
Eigene Produktseiten.
Ein Warenkorb.
Ein Zahlungsprozess.
Dazu ein Admin-Panel zur Verwaltung aller Hintergrundprozesse.
Die natürliche Annahme war:
"Das sollte schnell gehen."
Dann wurde die Entscheidung getroffen, sich auf einen KI-Code-Assistenten zu stützen.
Dort wurde es interessant.
Die KI für den größten Teil des Programmierens nutzen
Das Projekt wurde mit React entwickelt.
Anstatt jede Zeile manuell einzutippen, wurden Anfragen an die KI gesendet, um jeweils einen Teil zu erzeugen.
Eine solche Anfrage wie:
"Erstelle das Pizza-Card-Komponenten.
ergab sofort die entsprechende Komponente.
Nächstes Schritt:
"Erstelle den Warenkorb."
Bearbeitet.
Dann:
"Erstelle das Bezahlfenster."
Auch bearbeitet.
Dann:
"Erstelle ein Admin-Dashboard mit Statistiken, Bestellungen und Kundendaten."
Fertiggestellt.
Die Geschwindigkeit war wirklich beeindruckend.
Arbeit, die normalerweise Stunden dauern würde, wurde innerhalb von Minuten erledigt.
Zu den Ergebnissen gehörten:
- React-Komponenten
- Formulare
- Daten tabellen
- Dashboard-Widgets
- API-Integration
- Ladeindikatoren
- Fehlerbehandlung
- Layouts, die sich an die Bildschirmgröße anpassen
Und die Anwendung funktionierte tatsächlich.
Alles sah vielversprechend aus.
Es schien, als wäre der ideale Arbeitsablauf gefunden worden:
Idee → Prompt → Code → Veröffentlichung
Aber ein entscheidender Schritt fehlte.
Überprüfung dessen, was gebaut wurde.
Der Kunde sah den Code selbst nie
Vom Standpunkt des Kunden aus sah alles großartig aus.
Die Website funktionierte reibungslos.
Das Dashboard arbeitete einwandfrei.
Das Menü wurde korrekt angezeigt.
Die Bestellungen erschienen wie erwartet.
Visuell war alles hochwertig gestaltet.
Wo lag also das Problem?
Das Problem war von außen nicht sichtbar.
Hinter den Kulissen verwandelte sich die Codebasis allmählich in ein großes Wartungsproblem.
Das war zunächst nicht offensichtlich.
Aber je mehr Funktionen hinzugefügt wurden, zeichnete sich ein Muster ab.
Immer wieder kam derselbe Gedanke auf:
"Warte... wurde nicht bereits etwas fast Identisches gebaut?"
Dann kam eine wichtige Erkenntnis zutage:
KI ist tatsächlich sehr gut darin, funktionsfähigen Code zu erstellen.
Aber sauberen Code liefert sie nicht automatisch.
Problem #1: Wiederholte Logik überall
Fast identische Logiken befanden sich im ganzen Programm verteilt.
Zum Beispiel berechneten mehrere separate Funktionen die Gesamtbeträge unabhängig voneinander.
Eine sah so aus:
const total = price * quantity;
An anderer Stelle tauchte eine fast identische Version auf:
const orderTotal = price * quantity;
Und in einer weiteren Datei:
const cartAmount = price * quantity;
Alle drei führten im Grunde denselben Berechnungsvorgang durch.
Technisch gesehen war nichts kaputt.
Aber sobald sich die Preisregeln ändern mussten, musste jede einzelne Kopie aufgespürt und aktualisiert werden.
Dann wurde das erste Prinzip des sauberen Codes klar.
1. DRY – Wiederholen Sie sich nicht
Immer dann, wenn dieselbe Logik wiederholt auftaucht, ist die wichtige Frage:
Kann dies in eine einzige Quelle zusammengefasst werden?
Zum Beispiel:
const calculateItemTotal = (price, quantity) => {
return price * quantity;
};
Von da an kann jeder Teil der Anwendung die gleiche gemeinsame Funktion aufrufen.
Ziel ist es nicht, die Wiederverwendbarkeit überall durchzusetzen.
Einfach nur, sinnlose Duplikationen zu beseitigen.
Problem #2: Ein Komponente erledigte alles
Irgendwann wurde eine der generierten React-Dateien genauer untersucht.
Sie wuchs ständig weiter.
Zeile für Zeile.
Sie dehnte sich einfach weiter aus.
Diese einzige Komponente war für Folgendes verantwortlich:
- API-Anfragen
- Verwaltung des Formzustands
- Validierungslogik
- Sichtbarkeit von Modalen
- Ausgabe einer Tabelle
Kurz gesagt: Eine Datei hat im Grunde genommen die Hälfte der Anwendung allein betrieben.
Die offensichtliche Schlussfolgerung war:
"Die Wartung davon wird schwierig werden."
Deshalb wurde der Komponente in kleinere Teile aufgeteilt.
Anstatt diese Struktur beizubehalten:
Orders.jsx
↓
800+ lines
wurde sie umstrukturiert zu etwas wie:
Orders
├── OrderFilters
├── OrderTable
├── OrderRow
├── OrderModal
└── useOrders
Diese Umstellung führte direkt zum nächsten Prinzip.
2. Einzelne Verantwortung
Eine Komponente oder Funktion sollte eine klare Aufgabe haben.
Falls man nicht in einem Satz beschreiben kann, was eine Komponente tut, ist es sehr wahrscheinlich, dass sie zu viele Aufgaben übernimmt.
Zum Beispiel:
OrderTablezeigt eine Liste der Bestellungen an.
Das ist eine klare, präzise Beschreibung.
Vergleichen Sie das mit:
OrderTableholt Bestellungen ab, überprüft die Benutzerrechte, berechnet Gesamtbeträge, triggert Benachrichtigungen und zeigt alles in einer Tabelle an.
Eine solche Beschreibung ist ein Warnsignal.
Problem #3: Verschachtelte If-Anweisungen übernahmen den Code
Zu einem Zeitpunkt sah eine Teillogik im Projekt so aus:
if (user) {
if (user.isActive) {
if (user.isVerified) {
// create order
}
}
}
Es funktionierte korrekt.
Aber das Durchlesen war anstrengend.
Deshalb wurde es umgeschrieben als:
if (!user) return;
if (!user.isActive) return;
if (!user.isVerified) return;
// create order
Diese Version war auf den ersten Blick viel leichter verständlich.
Hier kommt die nächste Gewohnheit ins Spiel:
3. Frühzeitige Rückgänge / Schutzklauseln
Anstatt die Kernlogik unter mehreren Ebenen verschachtelter Bedingungen zu verbergen, hilft es, ungültige Fälle bereits früh zu behandeln und den Ablauf vorzeitig zu beenden.
Invalid?
↓
Return
Invalid?
↓
ReturnEverything okay?
↓
Do the actual work
Dadurch bleibt die Hauptlogik flach, lesbar und frei von unnötiger Einrückung.
Problem #4: Von der KI vorgeschlagene neue Komponenten für bereits existierende Elemente
Dieser Fehler war etwas peinlich.
Die Anfrage an die KI lautete:
"Erstellen Sie ein Bestätigungsmodul zum Löschens einer Bestellung."
Die KI reagierte damit, eine völlig neue Komponente zu erstellen.
Sie wurde fast ohne Fragen akzeptiert.
Dann führte eine schnelle Suche im Projekt zu etwas Wichtigem.
Eine Modul-Komponente existierte bereits.
Man hätte sie einfach wiederverwenden können.
In diesem Moment wurde etwas klar:
KI weiß nicht automatisch, was in einer gegebenen Codebasis bereits vorhanden ist.
Auch wenn das System es weiß, kann es dennoch entscheiden, etwas Neues zu erstellen, anstatt das Bestehende zu wiederverwenden.
Ein besserer Ansatz ist es, mit etwas wie folgendem anzusetzen:
"Bevor Sie eine neue Komponente erstellen, überprüfen Sie die vorhandene Codebasis auf Elemente, die wiederverwendet werden können."
Diese Erfahrung weist auf eine weitere Regel hin:
4. Wiederverwenden, bevor man erstellt
Vor dem Hinzufügen von:
- einer neuen Komponente
- einer neuen Hilfsfunktion
- einem neuen benutzerdefinierten Hook
- einem neuen API-Hilfsprogramm
sollte man fragen:
"Gibt es das bereits im Projekt?"
Eine saubere Codebasis wird nicht dadurch definiert, dass Dutzende wiederverwendbarer Elemente vorhanden sind.
Sie wird dadurch definiert, dass Entwickler das bereits Verfügbare wiederverwenden anstatt es heimlich zu duplizieren.
Problem #5: Variablenamen waren manchmal schrecklich
Code, der von KI erzeugt wird, kommt schnell.
Und es ist einfach, Variablenamen wie diese zu akzeptieren:
const data = ...
const result = ...
const x = ...
const temp = ...
Diese Namen kompilieren einwandfrei und verursachen keine Fehler.
Aber Monate später: Was bezieht sich eigentlich auf data?
Sind es datenbezogene Informationen zu Pizza?
Bestellinformationen?
Kundendaten?
Etwas, das mit einem Dashboard zusammenhängt?
Daher sollte die Benennung im Laufe eines Projekts bewusster erfolgen.
Anstatt zu schreiben:
const data = await getOrders();
ist eine klarere Version vorzuziehen:
const orders = await getOrders();
Und anstatt:
const x = users.filter(...);
liest sich das viel besser:
const activeUsers = users.filter(...);
Das führt zu einer weiteren einfachen Regel:
5. Verwenden Sie Namen, die den Code erklären
Beschreibende Benennung kann oft den Bedarf an Kommentaren völlig beseitigen.
Wenn man etwas wie folgt liest:
const activeUsers = users.filter(
(user) => user.isActive
);
Dies sagt Ihnen bereits genau, was vor sich geht.
Es ist nicht notwendig hinzuzufügen:
// Filter users who are currently active
Der Code spricht für sich.
Problem #6: Optimierung von Dingen, die keine Optimierung benötigen
Zu einem bestimmten Zeitpunkt in einem solchen Projekt ist es leicht, anzufangen zu denken:
"Dieser Code muss weiter optimiert werden."
Das führt oft dazu, sich mit Dingen wie folgendem auseinanderzusetzen:
useMemo()
useCallback()
und einigen anderen Leistungstricks.
Aber es lohnt sich, hier innezuhalten.
Optimierung ist nicht automatisch etwas Gutes.
Nehmen Sie eine triviale Berechnung wie folgende:
const total = price * quantity;
Es gibt keinen Grund, diese in ein kompliziertes Optimierungsmodell zu packen, nur weil die entsprechenden Werkzeuge vorhanden sind.
Dadurch würde der Code nur schwerer verständlich werden.
Das weist auf eine weitere Lektion hin:
6. Optimieren Sie nur, wenn es ein echtes Problem gibt
Greifen Sie nicht zur Optimierung, weil:
"Jemand im Internet sagte, diese Technik sei schneller."
Suchen Sie stattdessen zuerst das eigentliche Engpassproblem.
Wird ein Komponente zu oft neu gerendert?
Ist ein API-Aufruf langsam?
Ist eine Berechnung tatsächlich aufwendig?
Ist die Größe des Bundles zu groß?
Ist eine Datenbankabfrage ineffizient?
Erkennen Sie das eigentliche Problem, bevor Sie etwas ändern.
Nur dann sollte mit der Optimierung begonnen werden.
Sauberer Code plus unnötige Optimierung führt zu überflüssiger Komplexität.
Problem #7: Man bittet die KI nicht mehr, "alles zu reparieren"
Dies könnte die wichtigste Lektion aus einem solchen Projekt sein.
Zu einem bestimmten Zeitpunkt besteht die Versuchung, einfach zu sagen:
„Klären Sie einfach das ganze Projekt für mich auf.“
Aber es ist besser, davon abzusehen.
Was bedeutet „aufklären“ überhaupt in diesem Kontext?
KI könnte wie folgt antworten:
- Variable und Dateien umbenennen
- Die Ordnerstruktur neu ordnen
- Neuere Abstraktionen einführen
- Funktionen zusammenführen
- Code löschen, den sie für unnötig hält
- Die Architektur umstrukturieren
Einige dieser Änderungen könnten tatsächlich helfen.
Andere wären möglicherweise sinnlos.
Wieder andere könnten heimlich Fehler verursachen.
Ein langsamerer, schrittweiser Ansatz funktioniert besser.
Fangen Sie damit an, zu fragen:
„Schauen Sie sich dieses Projekt an, ändern aber vorerst nichts.“
Dann:
„Weisen Sie alle doppelten Logiken auf.“
Dann:
"Sagen Sie mir, welche dieser Duplikate tatsächlich repariert werden sollten."
Nur danach sollten die Vorschläge überprüft werden.
Dann wird eine Änderung vorgenommen.
Anschließend wird sie getestet.
Das wird zur Regel Nummer sieben:
7. Verstehen, bevor man refaktorisiert
Lassen Sie niemals eine KI Code anfassen, den man nicht zuerst vollständig verstanden hat.
Fangen Sie mit der Analyse an.
Sicherstellen Sie sich anschließend, dass die Logik verstanden wird.
Entscheiden Sie dann, was zu tun ist.
Vernichten Sie anschließend die Änderung.
Überprüfen Sie sie schließlich mit einem Test.
Was eine Pizza-Website veranschaulicht
Interessanterweise fragt ein Kunde selten:
"Ist Ihr Code sauber?"
Die Frage ist in der Regel einfacher:
"Funktioniert die Website?"
Und oft funktioniert sie tatsächlich.
Trotzdem tragen die Entwickler eine Verantwortung, die über die erste funktionierende Version hinausgeht.
Software bleibt nach der Veröffentlichung selten unverändert.
Irgendwann kommt ein Kunde zurück mit:
">Können wir eine Lieferverfolgung hinzufügen?"
Dann:
">Lassen Sie uns Rabattcodes hinzufügen."
Dann:
">Wir benötigen Unterstützung für mehrere Filialen."
Dann:
">Fügen Sie Konten für das Restaurantpersonal hinzu."
Dann:
">Wir möchten einige Berichte haben."
Bald schon ist diese kleine Pizasite zu einem vollwertigen System herangewachsen.
Dort beginnt gerade der Punkt, an dem sauberer Code die investierte Mühe rechtfertigt.
KI war nicht schuld
Es ist angebracht, hier fair zu sein.
Die KI trägt keine Schuld.
Das ist bei einer solchen Entwicklung tatsächlich von großem Wert.
Dadurch wird geholfen bei:
- schnellerer Arbeit
- Erprobung verschiedener Ansätze
- Bearbeitung wiederkehrender Programmieraufgaben
- Auffindung von Fehlern
- Erstellung von Komponentenstrukturen
- Durchdachung von Lösungen
Das eigentliche Problem liegt niemals darin, dass KI Code erzeugt.
Sondern darin, dass der generierte Code manchmal ohne ausreichende Prüfung akzeptiert wird.
Das sind zwei völlig unterschiedliche Probleme.
Ein überarbeiteter Arbeitsablauf für das Programmieren mit KI
Nach einem solchen Projekt macht ein Ansatzwechsel Sinn.
Der Prozess kann ungefähr so aussehen:
Understand the requirement
↓
Explore existing code
↓
Plan the solution
↓
Ask AI for implementation
↓
Review the generated code
↓
Simplify
↓
Test
↓
Refactor if necessary
Die KI übernimmt weiterhin einen großen Teil des eigentlichen Tippenens.
Doch mehr der Denkarbeit fällt wieder dem Entwickler zu.
Es scheint, als würde sich die Softwareentwicklung insgesamt in diese Richtung entwickeln.
Die KI schreibt den Code, aber die Codebasis gehört weiterhin Ihnen
Das ist die wichtigste Erkenntnis aus dieser ganzen Erfahrung.
Sobald die KI anfängt, Ihren Code zu erstellen, ist es verlockend anzunehmen:
"Die KI hat das geschrieben, also muss sie verstehen, was sie tut."
Diese Annahme hält nicht stand.
Das Eigentum an der Codebasis bleibt bei Ihnen.
Sie sind es, der sie in Zukunft weiterbetreut.
Sie sind es, der Fehler aufspüren muss, sobald sie auftauchen.
Sie sind es, der erklären muss, wie es funktioniert, an jemand anderen.
Sie sind es, der es Monate später erneut durchgehen und verstehen muss.
Irgendwann könnte ein anderer Entwickler das Projekt öffnen und sich fragen:
"Welche Überlegungen lagen dieser Vorgehensweise zugrunde?"
Idealerweise sollte der Code selbst diese Logik klar machen.
Sieben Gewohnheiten des sauberen Codes, an denen man festhalten sollte
Wenn ich diese gesamte Erfahrung zusammenfasse, sind das die Punkte, die bei mir hängen geblieben sind:
1. DRY
Vermeiden Sie es, dieselbe Logik ohne triftigen Grund an mehreren Stellen zu duplizieren.
2. Eindeutige Verantwortung
Sorgen Sie dafür, dass jede Funktion oder Komponente einen klar definierten Zweck hat.
3>Frühzeitige Rückgänge
Vermindern Sie die Verkettung von Schleifen, damit der Hauptlogikpfad leicht nachvollziehbar bleibt.
4>Vor der Erstellung wiederverwenden
Suchen Sie in der Codebasis nach bestehenden Lösungen, bevor Sie etwas Neues entwickeln.
5>Gute Benennung
Wählen Sie Namen, die klar zeigen, was eine Variable oder Funktion darstellt.
6>Optimieren mit Belegen
Zögern Sie mit der Hinzufügung von Komplexität, es sei denn, es gibt ein messbares Leistungsproblem, das dies rechtfertigt.
7>Vor dem Refactoring verstehen
KI kann Änderungsvorschläge machen, aber die Entscheidung, welche umgesetzt werden sollen, liegt bei Ihnen.
Fazit
Beim Start des Pizza-Website-Projekts ging ich davon aus, dass der Hauptvorteil der KI-Hilfe folgender sein würde:
reine Geschwindigkeit.
Rückblickend bin ich zu der Überzeugung gekommen, dass es einen größeren Vorteil gibt.
KI befreit den geistigen Raum für die Aspekte der Entwicklung, die tatsächlich Urteilsvermögen erfordern.
Anstatt Energie in Standardaufgaben zu investieren, können wir diese auf bessere Fragen lenken:
Ist das wirklich der richtige Ansatz?
Kann man das vereinfachen?
Gibt es bereits etwas Ähnliches im Projekt?
Hält dieses Design stand, wenn die nächste Funktion hinzukommt?
Könnte ein anderer Entwickler diesem Vorgehen folgen?
Das ist die eigentliche Schwierigkeit bei der Arbeit mit künstlicher Intelligenz unterstützter Entwicklung.
KI ist in der Lage, fast sofort Hunderte von Codezeilen zu erzeugen.
Die Überprüfung, ob diese Zeilen tatsächlich ihren Platz im Codebasis verdienen, liegt weiterhin bei uns.
Möglicherweise ist das die aktualisierte Definition von sauberem Code, da KI nun Teil des Prozesses ist:
Dass der Code läuft, ist nicht das Ziel. Die Fähigkeit, ihn später zu warten, schon.
Zusätzliche Literatur
- Warum der Zugang zu KI und nicht die Fähigkeit das eigentliche Abhängigkeitsrisiko darstellt — Dieser Artikel untersucht jüngste Vorkommnisse im Bereich der Exportkontrolle mit Claude und GPT-5.6, um zu argumentieren, dass der Zugang zu KI-Modellen eine volatile Größe ist, die unabhängig von der reinen Fähigkeit besteht.