Code-Review auf JavaScript: Was man prüfen sollte, damit der Code nicht auseinanderfällt

Code-Review auf JavaScript: Was man prüfen sollte, damit der Code nicht auseinanderfällt

Haben Sie jemals einen fremden Pull-Request geöffnet und gespürt, wie sich innerlich alles zusammenzieht? Als ob man auf ein verworrenes Kabelknäuel schaut, bei dem jeder Knoten ein potenzieller Bug ist. Code-Review auf JavaScript ist nicht einfach nur ein Häkchen im Task-Tracker. Es ist Ihre letzte Verteidigungslinie gegen das Chaos. Besonders in der dynamischen Welt von JS, wo Typisierung eine Illusion ist und „magisches“ Verhalten die Norm.

In diesem Artikel erkläre ich, worauf man bei der Überprüfung von JavaScript-Code wirklich achten sollte. Vergessen Sie die sinnlosen Diskussionen über Tabs vs. Leerzeichen. Wir sprechen über Dinge, die sich direkt auf Stabilität, Lesbarkeit und Leistung auswirken. Dies ist die Code-Review-Checkliste, die ich selbst verwende.

1. Sauberkeit von Funktionen und keine Seiteneffekte

Der erste und wichtigste Punkt. Eine Funktion sollte genau eine Sache tun und diese gut machen. Wenn Sie eine Funktion sehen, die gleichzeitig Daten validiert, eine Anfrage an den Server sendet und den globalen Zustand aktualisiert – das ist ein Alarmzeichen.

Was prüfen:

\n
• Anzahl der Argumente: Ideal: 0, maximal: 3. Wenn mehr – in ein Konfigurationsobjekt auslagern.
\n
• Mutation von Eingabedaten: Die Funktion sollte das übergebene Array oder Objekt nicht verändern. Das ist ein schwerwiegender Bug, der schwer zu finden ist.
\n
• Seiteneffekte: Jede Änderung der Außenwelt (console.log, Schreiben in eine Datei, Änderung des DOM) sollte explizit und gerechtfertigt sein.
\n

Schlechtes Beispiel:

let totalUsers = 0;\n\nfunction processUsers(users) {\n    for (let i = 0; i < users.length; i++) {\n        users[i].active = true; // Mutation der Eingabedaten!\n        totalUsers++;           // Seiteneffekt!\n        console.log(users[i]);  // Noch ein Seiteneffekt\n    }\n    return users;\n}

Gutes Beispiel:

function activateUsers(users) {\n    return users.map(user => ({ ...user, active: true }));\n}\n\n// Verwendung:\nconst activeUsers = activateUsers(users);\nconsole.log(`Aktiviert: ${activeUsers.length}`);

Denken Sie daran: Reine Funktionen sind die Grundlage für vorhersagbaren Code. Wenn Sie bei einem Code-Review eine Mutation sehen – schreiben Sie ruhig einen Kommentar. Dies ist einer der Hauptgründe für schwer zu findende Bugs in JavaScript.

2. Asynchronität: Promises und async/await

JS ist der König der Asynchronität, aber auch der König der Callback-Hölle. Achten Sie beim Review darauf, wie asynchrone Operationen behandelt werden. JavaScript-Code-Prüfung ohne Analyse von Promise-Ketten ist eine Farce.

Rote Flaggen:

\n
• Fehlende Fehlerbehandlung: Kein .catch() oder try/catch. Früher oder später wird dies die Anwendung zum Absturz bringen.
\n
• Verschachtelte Promises: Wenn Sie .then() innerhalb von .then() sehen – das ist ein Grund für ein Refactoring.
\n
• Vergessenes await: Die Funktion ist als async markiert, aber die Aufrufe darin sind ohne await. Das Ergebnis ist undefined statt Daten.
\n

Schlechtes Beispiel (fehlende Fehlerbehandlung):

async function fetchUserData(userId) {\n    const response = await fetch(`/api/users/${userId}`);\n    const data = await response.json();\n    return data;\n}

Gutes Beispiel:

async function fetchUserData(userId) {\n    try {\n        const response = await fetch(`/api/users/${userId}`);\n        if (!response.ok) {\n            throw new Error(`HTTP error! status: ${response.status}`);\n        }\n        return await response.json();\n    } catch (error) {\n        console.error('Fehler beim Laden des Benutzers:', error);\n        throw error; // Weiterwerfen, aber protokollieren\n    }\n}

Tipp für den Reviewer: Fordern Sie immer eine Erklärung, warum try/c