DE
RU
EN
ES
ZH
FR
PT
AR
HI
Einleitung: Wenn Code zu „riechen“ beginnt
Jeder Entwickler kennt dieses Gefühl. Sie öffnen eine Datei, die Sie vor drei Monaten geschrieben haben, und Ihr Gesicht wird lang. Irgendwo tief in Ihrer Seele hören Sie ein Flüstern: „Das habe nicht ich geschrieben, das war ein Anfänger.“ Aber der Rückspiegel ist gnadenlos: Sie waren es. Der Code funktioniert, die Tests bestehen, aber bei jeder neuen Funktion brauchen Sie immer länger. Kommt Ihnen das bekannt vor?
Das ist der Moment, über ein Refactoring von TypeScript-Code nachzudenken. Nicht über das vollständige Neuschreiben (das ist der Weg zur Hölle), sondern über chirurgisch präzise Verbesserungen, die den Code sauberer, verständlicher und sicherer machen. In diesem Artikel analysieren wir, wann man mit dem Refactoring beginnen sollte, wie man es ohne Schmerzen macht und warum TypeScript Ihnen dafür Superkräfte verleiht.
Wann sollte man TypeScript-Code refactoren?
Es gibt einen Mythos, dass Refactoring eine separate Aufgabe im Sprint ist. In der Praxis ist das beste Refactoring ein kontinuierlicher Prozess. Aber es gibt klare Signale, die schreien: „Stopp! Hier ist Ordnung nötig!“.
Die Drei-Regel (und noch zwei mehr)
Wenn Sie dasselbe Codefragment dreimal kopiert haben – extrahieren Sie es in eine Funktion oder Klasse. Wenn Sie sehen, dass ein Kollege Ihren Code kopiert hat – das ist das vierte Mal. TypeScript mit seiner strengen Typisierung macht diese Regel besonders wichtig: Die Duplizierung von Typen führt zu Datendeskalation.
Symptome von „schmutzigem“ Code in TypeScript
- Any-Chaos: Wenn in Ihrem Projekt
anyhäufiger vorkommt alsstring– das ist eine rote Flagge. TypeScript verliert seinen Sinn. - Monster-Funktionen: Eine Funktion mit über 200 Zeilen, die alles macht: validiert, parst, Anfragen sendet und die Benutzeroberfläche zeichnet.
- „Magische“ Zahlen und Zeichenfolgen:
if (status === 3)– was ist 3? Niemand weiß es, außer dem Autor, der bereits gekündigt hat. - Verletzung des DRY-Prinzips: Identische Schnittstellen sind über 10 Dateien verstreut.
- Tests sind schlimmer als der Code: Wenn man zum Testen einer Funktion einen Server, eine Datenbank hochfahren und Docker starten muss – sind Sie falsch abgebogen.
Merken Sie sich die Hauptregel: Ein Refactoring von TypeScript-Code sollte dann durchgeführt werden, wenn das Hinzufügen einer neuen Funktion länger dauert als das Neuschreiben von Grund auf. Das ist der Moment der Wahrheit.
Grundlegende Prinzipien: Wie man die Produktion nicht kaputt macht
Bevor Sie mit dem Refactoring beginnen, merken Sie sich die drei Säulen, auf denen sicheres Refactoring ruht:
- Tests – Ihre Versicherung. Ohne Testabdeckung ist Refactoring russisches Roulette. Schreiben Sie vor Beginn zumindest grundlegende Unit-Tests.
- Kleine Schritte. Versuchen Sie nicht, das gesamte Projekt über Nacht zu refactoren. Ein Modul – ein Commit.
- Der TypeScript-Compiler – Ihr Freund. Verwenden Sie strenge Einstellungen in
tsconfig.json:strict: true– das ist Ihr Lügendetektor.
Praktische Refactoring-Techniken mit Beispielen in TypeScript
Kommen wir zum interessantesten Teil – dem Code. Wir betrachten drei reale Situationen und zeigen, wie man sie verbessert.
1. any loswerden: Die Macht der Generics
Schlechtes Beispiel. Die Funktion akzeptiert alles und gibt alles zurück. Das ist nicht TypeScript, das ist JavaScript mit einer Maske.
// SCHLECHT: any tötet die Typisierungfunction getFirstElement(arr: any[]): any { if (arr.length === 0) { throw new Error('Array is empty'); } return arr[0];}
const num = getFirstElement([1, 2, 3]); // num: anyconsole.log(num.toUpperCase()); // Fehler zur Laufzeit, aber der Compiler schweigtGutes Beispiel. Wir verwenden Generics. Der Code wird sicherer und die IDE zeigt Typen an.
// GUT: Generics rettenfunction getFirstElement<T>(arr: T[]): T { if (arr.length === 0) { throw new Error('Array is em 
