Code Review in JavaScript: Was prüfen und wie man Feedback in der Praxis gibt

Einleitung: Warum Code Review nicht nur "Fehler finden" bedeutet

Code Review ist nicht nur eine Formalität oder eine Möglichkeit, Tippfehler zu finden. In der modernen Entwicklung mit JavaScript und Node.js ist es das wichtigste Werkzeug, um die Code-Qualität zu erhalten, Wissen im Team auszutauschen und technische Schulden zu vermeiden. Viele Entwickler reduzieren das Review jedoch auf die Überprüfung der Syntax und übersehen dabei architektonische Probleme, Leistung und Lesbarkeit.

In diesem Artikel analysieren wir, was genau in JavaScript-Code zu prüfen ist (am Beispiel von Node.js), und wie man Feedback gibt, um Kollegen nicht zu verletzen, sondern ihnen zu helfen, zu wachsen. Praktische Code-Beispiele helfen, den Stoff zu festigen.

1. Was in JavaScript-Code prüfen: Eine praktische Checkliste

Beginnen wir mit konkreten Prüfpunkten. Unterteilen wir sie in drei Ebenen: Syntax/Stil, Logik/Sicherheit und Architektur.

1.1. Code-Stil und Formatierung

Hier ist es einfach: Verwenden Sie einen Linter (ESLint) und einen Formatierer (Prettier). Im Review sollte es keine Diskussionen über Leerzeichen geben. Konfigurieren Sie die Einstellungen einmal im Projekt. Prüfen Sie, dass:

\n
• Der Code den Regeln von eslint-config-airbnb oder Ihren benutzerdefinierten Einstellungen entspricht.
\n
• Keine unnötigen console.log vorhanden sind (außer im Dev-Modus).
\n
• Variablennamen aussagekräftig sind: const userData, nicht const x.
\n

1.2. Logik der Asynchronität (Promise, async/await)

Dies ist ein häufiger Fehlerbereich in Node.js. Prüfen Sie:

\n
• Fehlerbehandlung in asynchronen Funktionen. Fehlendes try/catch kann zum Absturz des Prozesses führen.
\n
• Korrekte Verwendung von await innerhalb von Schleifen. Wenn Aufgaben nicht voneinander abhängen, verwenden Sie Promise.all.
\n

Schlecht:

// Sequenzielle Ausführung, obwohl parallel möglich\nconst results = [];\nfor (const id of ids) {\n  const data = await fetchData(id); // Warten auf jede Anfrage\n  results.push(data);\n}\n

Gut:

// Parallele Ausführung\nconst promises = ids.map(id => fetchData(id));\nconst results = await Promise.all(promises);\n

1.3. Sicherheit und Speicherlecks

Für Node.js kritisch:

\n
• Keine Injection: Verwenden Sie eval oder new Function nur bei dringendem Bedarf.
\n
• Schließen von Streams, Datenbankverbindungen und Dateideskriptoren.
\n
• Validierung von Eingabedaten. Vertrauen Sie niemals dem Request-Body (req.body).
\n

2. Wie man Feedback gibt: Psychologie und Taktik

Selbst eine perfekte Checkliste funktioniert nicht, wenn das Feedback beim Autor des Codes den Wunsch weckt, den PR zu schließen und zu kündigen. Hier sind einige Regeln.

2.1. Die "Sandwich"-Regel (optional, aber effektiv)

Beginnen Sie mit einem positiven Kommentar, weisen Sie dann auf das Problem hin und enden Sie mit Unterstützung. Zum Beispiel:

\n
• "Tolle Lösung mit Map für das Caching!"
\n
• "Hier gibt es jedoch ein potenzielles Problem mit der Mutation des ursprünglichen Arrays. Lass uns .map() anstelle von .forEach() mit push verwenden."
\n
• "Ansonsten ist der Code sauber, danke für den schnellen Fix!"
\n

2.2. Kommentieren Sie den Code, nicht die Person

Sagen Sie statt "Du hast eine schreckliche Schleife geschrieben" lieber "Diese Schleife kann durch Array.reduce ersetzt werden, um die Lesbarkeit zu verbessern". Vermeiden Sie das Pronomen "du" in negativem Kontext.

2.3. Geben Sie Kontext und Alternativen

Einfach "Das ist falsch" zu schreiben, ist schlecht. Erklären Sie warum und schlagen Sie eine Alternative vor. Beispiel für einen schlechten Kommentar:

"Verwende kein var."

Guter Kommentar:

"Hier erstellt var eine Variable im globalen Gültigkeitsbereich, was zu Fehlern führen kann. Lass es uns durch const ersetzen, da der Wert nicht überschrieben wird."