Code-Review in TypeScript: 10 Fehler, die Seniors nerven

Einleitung: Warum sieht Ihr Code-Review in TypeScript aus wie eine rote Lampe auf dem Pult?

Haben Sie jemals einen Pull-Request gesendet und eine Stunde später 20 Kommentare von einem Senior-Entwickler erhalten, von denen die Hälfte mit den Worten „das kann man besser machen“ begann? Kommt Ihnen bekannt vor. Wenn Sie in TypeScript schreiben, Ihr Code aber bei Kollegen immer noch den Wunsch weckt, ihn von Grund auf neu zu schreiben – dann ist dieser Artikel für Sie.

Wir bei PythonLib stoßen oft auf Situationen, in denen Entwickler, selbst wenn sie die Syntax von TypeScript kennen, immer wieder dieselben Fehler machen. Diese Fehler brechen den Code nicht, machen ihn aber unlesbar, unsicher und schwer wartbar. Heute zeige ich Ihnen 10 typische Anmerkungen, die Seniors in Code-Reviews zu TypeScript schreiben, und wie Sie sie vermeiden. Machen Sie sich bereit fürs Refactoring!

1. „Any“ – Ihr Feind, nicht Ihr Freund

Der häufigste Kritikpunkt in jedem Code-Review zu TypeScript ist die Verwendung von any. Es scheint einfacher, const data: any = await fetch(...) zu schreiben, als sich mit Typen auseinanderzusetzen. Aber Seniors sehen das wie ein rotes Tuch.

Schlecht:

function processUser(user: any) {  console.log(user.name.toUpperCase());}

Gut:

interface User {  id: number;  name: string;  email: string;}

function processUser(user: User): void {  console.log(user.name.toUpperCase());}

Warum ist das wichtig? TypeScript verliert seinen ganzen Sinn, wenn Sie any verwenden. Sie schalten das Typsystem buchstäblich aus. Wenn Daten von einer API kommen – erstellen Sie ein Interface. Wenn der Typ komplex ist – verwenden Sie unknown mit Prüfungen. Dies ist eine der wichtigsten TypeScript Best Practices.

2. Ignorieren des Strict Mode

Viele Projekte deaktivieren den Strict Mode in tsconfig.json, weil es „schneller ist“ oder „Typen nerven“. Ein Senior-Entwickler für TypeScript wird sofort bemerken, dass Ihr Code null und undefined nicht prüft.

Schlecht (strict: false):

function getLength(str: string) {  return str.length; // str könnte null sein, und das führt zu einem Fehler}

Gut (strict: true):

function getLength(str: string | null): number {  if (str === null) return 0;  return str.length;}

Tipp: Aktivieren Sie strict: true in tsconfig.json. Das zwingt Sie, sichereren Code zu schreiben. In einem Code-Review zu TypeScript ist das ein Pluspunkt, kein Minuspunkt.

3. Magie mit Typen: Übermäßige Komplexität

Manchmal versuchen Entwickler zu zeigen, wie gut sie sind, und schreiben Typen, bei denen selbst Seniors sich am Kopf kratzen. Zum Beispiel bedingte Typen mit verschachtelten Generics, wo ein einfaches Interface ausgereicht hätte.

Schlecht (Over-Engineering):

type DeepReadonly<T> = {  readonly [P in keyof T]: T[P] extends object ? DeepReadonly<T[P]> : T[P];};

Gut (Einfachheit):

interface Config {  readonly apiUrl: string;  readonly timeout: number;}

Seniors schätzen Lesbarkeit des Codes. Wenn Ihr Typ durch ein Interface mit drei Feldern ersetzt werden kann – tun Sie das. Machen Sie es nicht unnötig kompliziert.

4. Falsche Fehlerbehandlung

Ein typischer Fehler in Code-Reviews zu TypeScript ist ein try-catch mit any oder ein leerer catch-Block. Seniors werden Sie sofort darauf hinweisen.

Schlecht:

try {  const data = await fetchData();} catch (e) {  console.log('Fehler');}

Gut:

try {  const data = await fetchData();} catch (error: unknown) {  if (error instanceof Error) {    console.error(error.message);  } else {    console.error('Unbekannter Fehler', error);  }}

Verwenden Sie unknown für Fehler. Das erz