Code-Review in JavaScript: Was man prüfen und wie man Feedback geben sollte

Code-Review in JavaScript: Was man prüfen und wie man Feedback für Anfänger geben sollte

Code-Review (oder Code-Überprüfung) ist der Prozess der Überprüfung von Programmcode durch einen oder mehrere Entwickler, bevor er in den Hauptzweig des Projekts gelangt. Für Anfänger wirkt dieser Vorgang oft einschüchternd: „Was, wenn ich einen Bug übersehe?“, „Wie sage ich einem Kollegen, dass sein Code schlecht ist, ohne die Beziehung zu belasten?“.

In diesem Artikel schauen wir uns an, worauf man bei einem Code-Review in JavaScript (einschließlich Node.js) achten sollte und wie man Feedback so gibt, dass es nützlich und nicht verletzend ist. Das Material richtet sich an angehende Entwickler, die gerade erst mit Reviews beginnen.

Was man in JavaScript-Code prüfen sollte: Eine Checkliste für Anfänger

Um das Review zu strukturieren, unterteilen wir die Prüfung in mehrere Schlüsselbereiche. Versuchen Sie nicht, alles auf einmal abzudecken – beginnen Sie mit den kritischsten Punkten.

1. Funktionalität und Logik

Stellen Sie zunächst sicher, dass der Code die gestellte Aufgabe löst. Führen Sie ihn lokal aus (falls möglich) oder gehen Sie gedanklich alle Ausführungspfade durch. Hier sind typische Fragen:

\n
• Werden Grenzfälle korrekt behandelt (leeres Array, null, undefined)?
\n
• Gibt es „magische Zahlen“ (Zahlen ohne Erklärung, z. B. if (x > 86400) anstelle von const ONE_DAY_IN_SECONDS = 86400)?
\n
• Funktioniert der asynchrone Code korrekt (Promise, async/await)?
\n

// Schlecht: magische Zahl\nif (user.lastLogin < Date.now() - 86400000) { ... }\n\n// Gut: Konstante mit Namen\nconst ONE_DAY_MS = 24 * 60 * 60 * 1000;\nif (user.lastLogin < Date.now() - ONE_DAY_MS) { ... }

2. Codestil und Formatierung

Auch wenn viele Projekte Prettier und ESLint verwenden, sollte man manuell prüfen:

\n
• Einhaltung eines einheitlichen Stils (Einrückungen, Anführungszeichen, Semikolons).
\n
• Korrekte Benennung von Variablen, Funktionen und Klassen (camelCase für Variablen, PascalCase für Klassen).
\n
• Kein auskommentierter Code – er verunreinigt nur die Datei.
\n

// Schlecht: nichtssagender Name\nconst d = new Date();\nconst arr = getData(d);\n\n// Gut: Name beschreibt den Inhalt\nconst currentDate = new Date();\nconst usersData = fetchUsersData(currentDate);

3. Leistung und Sicherheit

Für Node.js sind besonders wichtig:

\n
• Vermeidung von blockierenden Operationen im Hauptthread (synchrones Lesen von Dateien, schwere Schleifen).
\n
• Prüfung auf Speicherlecks (z. B. vergessene Timer oder Event-Listener).
\n
• Validierung von Benutzereingaben (Schutz vor SQL-Injection, XSS).
\n

// Schlecht: synchrones Lesen blockiert die Event Loop\nconst data = fs.readFileSync('bigfile.json', 'utf8');\n\n// Gut: asynchrones Lesen\nconst data = await fs.promises.readFile('bigfile.json', 'utf8');

Wie man Feedback gibt: Prinzipien eines konstruktiven Reviews

Nachdem Sie nun wissen, was zu prüfen ist, betrachten wir die wichtigste Fähigkeit im Code-Review – die Fähigkeit, Anmerkungen zu kommunizieren. Ihr Ziel ist es, den Code zu verbessern, nicht sich selbst auf Kosten des Autors zu profilieren.

1. Seien Sie konkret und begründet

Schreiben Sie statt „Dieser Code ist schlecht“ lieber: „Hier gibt es ein potenzielles Leistungsproblem: Der Aufruf von Array.find() in einer Schleife ergibt eine Komplexität von O(n²). Ersetzen wir es durch eine Map.“ Der Autor versteht dann genau, was falsch ist und wie es behoben werden kann.

2. Verwenden Sie „Ich“-Aussagen und stellen Sie Fragen

Formulierungen wie „Ich bin mir nicht sicher, ob dieser Code den Fall eines leeren Arrays behandelt. Können wir eine Prüfung hinzufügen?“ klingen sanfter als „Du hast vergessen, das leere Array zu behandeln.“ Dies reduziert die Abwehrhaltung und fördert den Dialog.

3. Loben Sie gute Lösungen

Code-Review ist nicht nur Kritik. Wenn Sie eine elegante Lösung oder eine hervorragende Architektur sehen, heben Sie dies unbedingt hervor. Zum Beispiel: „Tolle Idee, die