Code-Review in TypeScript: Was prüfen und wie man Feedback gibt

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

Code-Review ist nicht nur eine Formalität, sondern ein mächtiges Werkzeug zur Verbesserung der Codequalität. In TypeScript mit seinem reichhaltigen Typsystem kann das Review besonders effektiv sein. In diesem Artikel schauen wir uns an, worauf man bei der Überprüfung von TypeScript-Code achten sollte und wie man Feedback gibt, das nützlich und nicht verletzend ist. Alle Beispiele basieren auf echtem Code.

1. Typen und Annotationen: `any` vermeiden und Strenge nutzen

Das Erste, was beim Review von TypeScript-Code ins Auge fällt, sind die Typen. TypeScript wurde entwickelt, um Fehler bereits zur Kompilierzeit zu erkennen, daher ist any eine rote Flagge.

Was prüfen:

\n
• Vorhandensein von any. Jedes any muss begründet sein. Bei einer Migration von JS ist es okay, aber in neuem Code nicht.
\n
• Korrektheit der Typen. Verwenden Sie nicht string, wo ein enum oder Union-Typ benötigt wird.
\n
• Übermäßige Typisierung. TypeScript kann Typen ableiten. Schreiben Sie nicht const x: number = 5, sondern const x = 5.
\n
• Strenge Einstellungen. Prüfen Sie, ob in der tsconfig.json strict: true, noImplicitAny und strictNullChecks aktiviert sind.
\n

Beispiel für schlechten Code:

function processData(data: any) {\n  return data.name.toLowerCase();\n}

Wie beheben:

interface User {\n  name: string;\n}\n\nfunction processData(data: User): string {\n  return data.name.toLowerCase();\n}

Wie Feedback geben:

Sagen Sie statt „Du verwendest any, das ist schlecht“: „Hier deaktiviert any die Typprüfung. Lass uns ein User-Interface definieren – das erhöht die Sicherheit und Lesbarkeit des Codes.“

2. Umgang mit null und undefined: strictNullChecks rettet Leben

Fehler wie Cannot read property of undefined sind Klassiker. TypeScript mit strictNullChecks hilft, sie zu vermeiden, aber nur, wenn der Entwickler nullable-Werte korrekt behandelt.

Was prüfen:

\n
• Prüfung auf null/undefined vor dem Zugriff auf Eigenschaften.
\n
• Verwendung von Optional Chaining (?.) – das ist modern und sicher.
\n
• Der !-Operator (Non-null Assertion) – nur verwenden, wenn Sie zu 100% sicher sind, dass der Wert nicht null ist. Besser durch eine explizite Prüfung ersetzen.
\n
• Korrekte Verwendung von ?? (Nullish Coalescing) anstelle von || für Standardwerte.
\n

Beispiel für schlechten Code:

function getCity(user: User | null): string {\n  return user!.address!.city; // Gefährlich!\n}

Wie beheben:

function getCity(user: User | null): string {\n  return user?.address?.city ?? 'Unknown';\n}

Wie Feedback geben:

„Die Verwendung von ! ist hier riskant – wenn user null ist, kommt es zu einem Fehler. Ersetzen wir es durch ?. und ?? – das ist sicher und lesbar.“

3. Generics und Hilfstypen: Nicht unnötig verkomplizieren

Generics sind eine mächtige Funktion, aber man kann sie leicht überkomplizieren. Der Reviewer sollte auf ein Gleichgewicht zwischen Flexibilität und Lesbarkeit achten.

Was prüfen:

\n
• Übermäßige Komplexität. Wenn ein Generic nur einmal verwendet wird, ist es vielleicht nicht nötig.
\n
• Korrekte Verwendung von extends – schränken Sie Generics ein, damit sie nicht alles akzeptieren.
\n
• Hilfstypen (Partial, Pick, Omit, Record) – ihre Verwendung vereinfacht den Code.
\n
• Rückgabetypen – eine Funktion mit Generic