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

Einleitung: Warum Code-Reviews in TypeScript wichtig sind

Ein Code-Review ist nicht nur eine formelle Prüfung des Codes vor dem Merge. Es ist ein mächtiges Werkzeug zur Verbesserung der Projektqualität, zum Wissensaustausch im Team und zur frühzeitigen Vermeidung von Fehlern. Wenn es um TypeScript geht, gewinnt das Code-Review eine besondere Bedeutung: Statische Typisierung, ein leistungsstarkes Generics-System und strenge Compiler-Einstellungen ermöglichen es, viele Fehler bereits vor dem Start der Anwendung abzufangen. Dennoch gibt es auch in TypeScript Fallstricke, die leicht übersehen werden können.

In diesem Artikel besprechen wir, worauf bei der Überprüfung von TypeScript-Code zu achten ist und wie man Feedback so gibt, dass es nützlich und nicht verletzend ist.

1. Typisierung und Generics: Lassen Sie nicht zu, dass any alles ruiniert

Eines der Hauptziele von TypeScript ist es, Typen explizit zu machen. Wenn im Code any vorkommt, ist das fast immer eine rote Flagge. Überprüfen Sie beim Code-Review:

• Fehlen von any. Ersetzen Sie es durch unknown mit anschließender Typprüfung oder durch einen konkreten Typ.
• Korrektheit von Generics. Stellen Sie sicher, dass Typparameter nicht verloren gehen oder zu weit gefasst werden. Zum Beispiel:

// Schlecht: Typ geht verlorenfunction getFirst(arr: any[]): any {    return arr[0];}

// Gut: Typ wird durch Generics erhaltenfunction getFirst<T>(arr: T[]): T | undefined {    return arr[0];}

• Typisierung von API-Antworten. Wenn JSON vom Server kommt, sollte es durch ein Interface beschrieben werden, nicht durch any.
• Utility Types. Verwenden Sie Partial, Pick, Omit für flexible Arbeit mit Objekten – das reduziert Code-Duplizierung.

Tipp: Aktivieren Sie in der tsconfig.json die Flags strict: true und noImplicitAny: true – das eliminiert die meisten Probleme bereits auf Kompilierungsebene.

2. Logik und Fehlerbehandlung: Schweigen Sie Probleme nicht tot

TypeScript schützt nicht vor logischen Fehlern, daher sollte das Code-Review die Geschäftslogik und Ausnahmebehandlung prüfen.

Worauf zu achten ist:

• Behandlung von Grenzfällen. Was passiert, wenn das Array leer ist, das Objekt null oder der String leer ist? Beispiel:

// Schlecht: Vorhandensein des Elements wird nicht geprüftfunction getUserName(users: User[], id: string): string {    return users.find(u => u.id === id)!.name; // kann mit Fehler abstürzen}

// Gut: Prüfung erfolgtfunction getUserName(users: User[], id: string): string | null {    const user = users.find(u => u.id === id);    return user ? user.name : null;}

• Asynchrone Operationen. Stellen Sie sicher, dass Promises korrekt mit async/await behandelt werden und Fehler in try/catch abgefangen werden.
• Vermeidung von Mutationen. Wenn eine Funktion Eingabedaten nicht ändern soll, verwenden Sie readonly und immutable Methoden (z. B. map anstelle von forEach mit Änderung des externen Arrays).

3. Codestil und Lesbarkeit: Code wird für Menschen geschrieben

Selbst perfekt typisierter Code kann unlesbar sein. Das Code-Review ist ein hervorragender Zeitpunkt, um über den Stil zu diskutieren.

Wichtige Punkte:

• Benennung. Variablen, Funktionen und Klassen sollten ihren Zweck erkennen lassen. Vermeiden Sie einbuchstabige Namen (außer für Schleifenindizes). Beispiel: fetchUserData ist besser als getData.
• Funktionsgröße. Eine Funktion sollte nicht mehr als eine Sache tun. Wenn sie länger als 20-30 Zeilen ist, ist das ein Grund, über Refactoring nachzudenken.
• Kommentare. Kommentare sollten erklären, warum der Code so geschrieben ist, nicht was er tut. Wenn ein Kommentar den Code dupliziert, löschen Sie ihn.
• Formatierung. Verwenden Sie