Code Review auf TypeScript: 7 Dinge, die ich überprüfe

Einleitung: Warum „es kompiliert einfach“ ein schlechtes Kriterium ist

Stellen Sie sich vor: Sie öffnen einen Pull Request auf GitHub, sehen das grüne CI-Häkchen und hören eine innere Stimme: „Die Typen passen – also ist der Code korrekt.“ Kommt Ihnen das bekannt vor? Wenn ja, dann tappen Sie in die Falle, die wir „falsches Sicherheitsgefühl von TypeScript“ nennen.

TypeScript ist kein Allheilmittel. Es fängt keine logischen Fehler, prüft keine Geschäftsanforderungen und garantiert schon gar nicht, dass Ihr Code nicht zur Laufzeit auseinanderfällt. Deshalb ist ein Code Review auf TypeScript kein „mal kurz drüberlesen“, sondern ein systematischer Ansatz. In diesem Artikel erkläre ich, worauf Sie wirklich achten sollten, wenn Sie TypeScript-Code reviewen. Ich blogge auf PythonLib, und hier sind wir es gewohnt, in die Tiefe zu gehen – machen Sie sich bereit.

1. Der Typ any: ein rotes Tuch

Das Offensichtlichste, aber irgendwie das Häufigste. any ist der Ausschalter von TypeScript. Wenn Sie any im Code sehen, ist Ihre Aufgabe herauszufinden: Ist das Faulheit des Autors oder ein wirklich gerechtfertigter Fall?

Schlechtes Beispiel:

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

Hier verlieren wir alle Typinformationen. Wenn data als null oder undefined kommt – hallo, Laufzeitfehler.

Gutes Beispiel:

interface UserData {\n    name: string;\n    age?: number;\n}\n\nfunction processData(data: UserData) {\n    return data.name.toLowerCase();\n}

Was im Code Review prüfen: Wenn any dennoch verwendet wird (z. B. für die Arbeit mit JSON unbekannter Struktur), verlangt der Autor dann eine Eingabevalidierung? Oft maskiert any das Fehlen einer ordentlichen Typisierung für externe Daten.

2. Strict Mode: Schalten Sie ihn nicht aus

Das Erste, was ich in der tsconfig.json überprüfe, ist das Flag strict: true. Fehlt es, entgehen Ihnen eine ganze Reihe von Prüfungen: strictNullChecks, noImplicitAny, strictFunctionTypes und andere.

Ohne strictNullChecks können Sie schreiben:

const user = getUser(); // kann null zurückgeben\nconst name = user.name; // TS meckert nicht, aber zur Laufzeit stürzt es ab

Im Code Review: Wenn Sie sehen, dass ein Projekt ohne Strict Mode läuft – schlagen Sie Alarm. Das ist technische Schuld, die exponentiell wächst. Es ist besser, einen Tag damit zu verbringen, den Strict Mode zu aktivieren und Fehler zu beheben, als einen Monat damit, Bugs in der Produktion zu jagen.

3. Generics: Macht und Verantwortung

Generics sind die Superkraft von TypeScript. Aber mit großer Macht kommt große Verantwortung. Im Code Review schaue ich immer: Hat der Autor die Typen überkompliziert?

Beispiel für übermäßige Komplexität:

function identity<T extends Record<string, unknown>>(arg: T): T {\n    return arg;\n}

Warum T auf Record<string, unknown> einschränken, wenn wir einfach dasselbe zurückgeben? Es reicht:

function identity<T>(arg: T): T {\n    return arg;\n}

Was prüfen:

\n
• Werden Generics dort verwendet, wo Flexibilität nötig ist, oder könnte man mit einem konkreten Typ auskommen?
\n
• Gibt es überflüssige Einschränkungen (extends), die die Wiederverwendung behindern?
\n
• Sind die Typen korrekt abgeleitet – muss der Nutzer manuell <SomeType> angeben, wo TS es selbst erraten könnte?
\n

4. unknown vs any: Wählen Sie die richtige Waffe

Wenn Sie mit Daten arbeiten, deren Typ Ihnen unbekannt ist (API, localStorage, Benutzereingaben), verwenden Sie unknown und nicht any. unknown zwingt Sie, den Typ vor der Verwendung explizit zu prüfen.

Schlecht: