Typsicherheits-Review

Das Problem

TypeScript verspricht Typsicherheit, doch Entwickler untergraben sie routinemaessig. any verstreuen bringt den Compiler zum Schweigen, verbirgt aber echte Bugs. Fehlende Null-Checks crashen zur Laufzeit trotz Strict Mode. Zu breite Union-Typen erzwingen unsichere Type Assertions. Das Ergebnis: TypeScript, das ein falsches Sicherheitsgefuehl vermittelt — die Typen kompilieren, aber der Code wirft in Produktion trotzdem Cannot read property of undefined.

Der Prompt

Pruefe den folgenden TypeScript-Code auf Typsicherheit. Handle als TypeScript-Architekt, der Strict-Mode Best Practices durchsetzt.

KONTEXT: [z.B. React-Frontend, Node.js-API, Shared Library]
STRICT MODE: [ja/nein — ist strict: true in tsconfig?]

CODE:
[TypeScript-Code hier einfuegen]

Analysiere in diesen Typsicherheits-Dimensionen:

1. **any / unknown Audit**
   - Jedes `any` markieren — ist es wirklich unvermeidbar oder nur bequem?
   - Sollte `any` durch `unknown`, einen korrekten Typ oder ein Generic ersetzt werden?
   - Auf implizites `any` durch fehlende Return-Typen oder Parameter pruefen

2. **Null-Sicherheit**
   - Werden optionale Werte vor dem Zugriff geprueft (Nullish Coalescing, Optional Chaining)?
   - Wird der Non-Null-Assertion-Operator (!) verwendet? Ist er gerechtfertigt?
   - Spiegeln Funktionssignaturen korrekt wider, wann null/undefined moeglich ist?

3. **Generic-Korrektheit**
   - Werden Generics dort eingesetzt, wo sich Typen mit verschiedenen Parametern wiederholen?
   - Sind Generic Constraints (`extends`) gesetzt, um Missbrauch zu verhindern?
   - Sind Generics ueberengineert (3+ Typparameter fuer einfache Anwendungsfaelle)?

4. **Type Narrowing**
   - Werden Discriminated Unions statt Type Assertions verwendet?
   - Behandeln Switch/If-Ketten alle Union-Mitglieder erschoepfend?
   - Wird `as` Type Assertion verwendet? Koennte ein Type Guard es ersetzen?

5. **Interface-Design**
   - Sind Interfaces schlank (keine optionalen Properties, die immer vorhanden sind)?
   - Sind geteilte Typen zentral abgelegt (nicht ueber Dateien dupliziert)?
   - Nutzen Funktionsparameter den engstmoeglichen Typ?

6. **Runtime-Compile-Alignment**
   - Passen Typen zu den tatsaechlichen API-Responses (mit zod/io-ts validiert)?
   - Sind externe Datengrenzen typisiert und validiert?
   - Koennte eine Type Assertion einen Laufzeit-Shape-Mismatch maskieren?

Fuer jedes Problem liefere:
- **Ort**: Datei und Zeile
- **Risiko**: Welcher Bug dies zur Laufzeit verursachen kann
- **Schweregrad**: Unsicher (Laufzeit-Crash) / Schwach (reduzierte Sicherheit) / Stil
- **Fix**: Korrekt typisierter Ersatzcode

Beispielausgabe

## Typsicherheits-Review: 7 Probleme gefunden

### Unsicher: Nicht validierte API-Response
Ort: src/api/users.ts:15
Code: `const data = await res.json() as User[]`
Risiko: Bei API-Shape-Aenderung verbirgt `as` den Mismatch — Zugriff auf data.name crasht.
Fix:
  import { z } from 'zod';
  const UserSchema = z.object({ id: z.number(), name: z.string() });
  const data = z.array(UserSchema).parse(await res.json());

### Schwach: Implizites any im Event Handler
Ort: src/components/Form.tsx:28
Code: `const handleChange = (e) => setState(e.target.value)`
Fix: `const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => setState(e.target.value)`

Wann verwenden

Beim Review von TypeScript-Pull-Requests, bei JavaScript-Migration oder beim Audit einer Codebasis vor dem Aktivieren von Strict Mode ausfuehren. Besonders wertvoll fuer Shared Libraries und API-Grenzschichten, wo Typ-Mismatches den groessten Schaden anrichten.

Profi-Tipps

• tsconfig mitliefern — Strict-Mode-Einstellungen aendern grundlegend, was als Problem zaehlt.
• Auf Grenzen fokussieren — Typsicherheit ist am wichtigsten an Dateneingangspunkten: API-Responses, Formulareingaben, URL-Parameter, localStorage-Reads.
• Migrationsplan anfordern — bei vielen any-Typen nachfragen: “Sortiere diese nach Risiko und gib mir einen schrittweisen Migrationsplan.”