Senior TypeScript Entwickler für die Modernisierung von Legacy Code

Woran Sie merkt, dass der Code Sie bremst

Legacy Code ist kein Schimpfwort. Meist ist es Code, der Geld verdient, sonst hätte ihn längst jemand abgeschaltet. Problematisch wird er, wenn er Veränderung verhindert. Die Anzeichen sind in fast allen Unternehmen ähnlich.

• Jede Änderung an einer Stelle bricht etwas an einer anderen, und niemand weiß vorher, wo.
• Es gibt ein Modul, das nur noch eine Person anfassen mag, und diese Person hat bald Urlaub.
• Neue Leute brauchen Monate, bis sie produktiv sind.
• Automatische Tests fehlen oder laufen seit Wochen rot, und alle haben sich daran gewöhnt.
• Abhängigkeiten sind Jahre alt, etwa AngularJS, dessen Support Ende 2021 ausgelaufen ist, oder Versionen von Node.js ohne Sicherheitsupdates.

Treffen zwei oder mehr Punkte zu, zahlen Sie bereits jeden Monat für den Zustand, nur steht er in keiner Rechnung. Er steckt in langsameren Releases, in Fehlern beim Kunden und in Leuten, die irgendwann kündigen, weil ihnen die Arbeit keinen Spaß mehr macht. Auf der Seite zum JavaScript Entwickler beschreiben wir, wie wir solche Codebasen typischerweise angehen.

Warum hier Erfahrung mehr zählt als Tempo

Modernisierung ist vor allem Risikomanagement. Es geht nicht darum, möglichst schnell möglichst viel neu zu schreiben, sondern darum, das System Stück für Stück sicherer veränderbar zu machen, während es weiterläuft. Darin unterscheidet sich ein Senior am deutlichsten von jemandem mit weniger Erfahrung.

Ein Senior TypeScript Entwickler weiß, welche Teile Sie jetzt nicht anfassen solltet. Er schätzt realistisch, statt zu versprechen, und er kann einer Geschäftsführung erklären, warum der nächste Monat in Tests fließt und nicht in Features. Vor allem kann er Nein sagen, wenn ein Umbau mehr Risiko bringt als Nutzen.

Seniorität hat dabei wenig mit Jahren zu tun. Es gibt Leute mit zwölf Jahren Erfahrung, die zwölfmal dasselbe Jahr erlebt haben. Woran Sie echte Erfahrung erkennt, steht weiter unten in diesem Beitrag.

Schrittweise statt Big Bang

Die Versuchung ist groß, alles neu zu bauen. Die Geschichte der Softwareentwicklung ist voll von Neuentwicklungen, die Jahre dauerten, während die alte Anwendung weiterlaufen musste und niemand mehr neue Features bekam. Der Netscape Browser ist das bekannteste Beispiel dafür.

Bewährt hat sich das Muster, das Martin Fowler Strangler Fig nennt. NIhr Code wächst um den alten herum, übernimmt Funktion für Funktion, und das alte System wird kleiner, bis es abgeschaltet werden kann. Für eine Migration von JavaScript zu TypeScript sieht das in der Praxis so aus.

1. Build und Tests stabilisieren. Eine Pipeline, die zuverlässig durchläuft, und Tests für die wichtigsten Abläufe, bevor irgendetwas umgebaut wird.
2. TypeScript einführen, ohne etwas umzuschreiben. Mit allowJs laufen JavaScript und TypeScript nebeneinander, mit checkJs und Kommentaren im JSDoc Format bekommt auch alter Code schon Typprüfungen.
3. Grenzen zuerst typisieren. Schnittstellen, Datenmodelle und alles, was von außen kommt. Dort entstehen die meisten Fehler, und dort bringen Typen am meisten.
4. Strenge schrittweise erhöhen. Zuerst strictNullChecks, weil fehlende Prüfungen auf null die häufigste Fehlerquelle sind, danach die übrigen Optionen des strikten Modus.
5. Modul für Modul umziehen. Jedes Modul wird vollständig migriert, getestet und ausgerollt, bevor das nächste drankommt.

Vier Fallstricke, die eine Migration ausbremsen

Die meisten Migrationen scheitern nicht an der Technik, sondern an Gewohnheiten, die sich unterwegs einschleichen. Diese vier sollte jemand im Team im Blick behalten.

• any als Dauerlösung. Wer jede schwierige Stelle mit any zuklebt, hat am Ende TypeScript Dateien ohne die Vorteile von TypeScript. Eine Regel im Linter und eine Zahl, die jeden Monat sinken muss, halten das in Schach.
• Typen, die lügen. Eine Behauptung mit as sagt dem Compiler, er solle vertrauen, auch wenn die Daten etwas anderes liefern. An den Grenzen gehört deshalb eine Prüfung zur Laufzeit dazu, etwa mit Zod.
• Riesige Pull Requests. Ein Review über zweihundert Dateien liest niemand gründlich. Kleine Schritte sind langsamer im Gefühl und schneller im Ergebnis.
• Migration und Umbau im selben Schritt. Wer Typen einführt und gleichzeitig Logik ändert, findet Fehler hinterher kaum noch. Die Regel lautet deshalb, zuerst nur Typen und erst danach Refactoring.

Ein Senior achtet auf diese Punkte nicht nur im eigenen Code, sondern auch in den Reviews für das restliche Team. So entsteht eine gemeinsame Arbeitsweise, die auch dann weiterträgt, wenn die externe Unterstützung wieder weniger wird.

Ein Compiler-Upgrade als guter Anlass

Seit dem 8. Juli 2026 ist TypeScript verfügbar. Der Compiler wurde nach Go portiert und ist laut Microsoft bei vollständigen Builds typischerweise zwischen acht und zwölf Mal so schnell. Beim Code von VS Code sank die Zeit für einen Build von rund 126 auf knapp 11 Sekunden. Für große Codebasen, in denen der Typecheck bisher Minuten dauerte, ist das im Alltag ein großer Unterschied.

Für Legacy Projekte hat die neue Version aber einen Haken. TypeScript übernimmt die Standards von Version 6, und die sind streng. Der strikte Modus ist jetzt voreingestellt, und alte Einstellungen wie target es5, die Modulauflösung node10 oder baseUrl führen zu harten Fehlern. Wer noch mit einer Konfiguration von vor fünf Jahren arbeitet, muss also zuerst aufräumen.

Dazu kommt, dass TypeScript.0 noch keine stabile programmatische API mitbringt. Werkzeuge, die direkt auf den Compiler zugreifen, etwa Linter, laufen deshalb vorerst parallel mit TypeScript 6. Für Vue, Astro, Svelte oder MDX bleibt der Editor zunächst auf Version 6, und auch die Typprüfung in Angular Templates nutzt TypeScript noch nicht. Eine neue API kündigt Microsoft für Version 7.1 an.

Ein erfahrener Entwickler plant das deshalb in zwei Schritten. Zuerst geht es auf TypeScript 6 mit den neuen Standards, und alle Warnungen werden behoben. Danach kommt TypeScript für den Build auf der Kommandozeile und in der Pipeline, während der Editor dort, wo es nötig ist, noch mit Version 6 arbeitet. Wie wir das in Projekten umsetzen, steht auf der Seite TypeScript Entwickler mieten, für Projekte mit Vue und Angular auf den jeweiligen Seiten.

Was Sie während der Modernisierung messen solltet

Ohne Zahlen wird Modernisierung zur Glaubensfrage. Mit ein paar einfachen Kennzahlen seht Sie jeden Monat, ob sich der Aufwand lohnt.

• Anteil der Dateien in TypeScript und Zahl der verbliebenen any Typen
• Dauer von Build und Typecheck in der Pipeline
• Fehler in Produktion pro Release
• Durchlaufzeit eines Tickets von der Idee bis zum Livegang
• Zeit, bis eine neue Person ihren ersten Pull Request einreicht

Wichtig ist der Trend, nicht der absolute Wert. Wenn die Zahl der Fehler sinkt und die Durchlaufzeit kürzer wird, seid Sie auf dem richtigen Weg, auch wenn noch die Hälfte des Codes in JavaScript liegt.

Die ersten 90 Tage

Ein realistischer Plan für ein Vierteljahr sieht bei einer mittelgroßen Codebasis ungefähr so aus.

Erster Monat

Analyse und Absicherung. Der Senior liest Code, spricht mit dem Team und erstellt eine Landkarte der Risiken. Eine einfache Methode ist ein Blick in die Historie von Git. Dateien, die sehr oft geändert werden und gleichzeitig viele Fehler verursachen, sind die heißen Stellen. Parallel wird die Pipeline stabil, und die wichtigsten Abläufe bekommen Tests.

Zweiter Monat

Grenzen und erste Strenge. TypeScript ist eingeführt, Schnittstellen und Datenmodelle sind typisiert, und in den ersten Modulen läuft strictNullChecks. Das Team sieht die ersten Fehler, die der Compiler abfängt, bevor sie beim Kunden landen.

Dritter Monat

Das erste Modul ist komplett. Es ist migriert, getestet und läuft im strikten Modus. Die Kennzahlen zeigen, was es gebracht hat, und auf dieser Basis plant Sie das nächste Quartal.

Woran Sie einen Senior TypeScript Entwickler erkennt

Im Gespräch zeigen sich Seniors weniger durch Antworten als durch Fragen. Wer zuerst wissen will, welche Teile des Systems das meiste Geld verdienen und woher die meisten Beschwerden kommen, denkt in Risiken statt in Technologien.

Diese drei Fragen helfen bei der Einschätzung.

• Welche Datei würdest du in unserer Codebasis als letzte anfassen, und warum?
• Wie würdest du nachweisen, dass eine Migration nichts kaputt gemacht hat?
• In welchem Fall würdest du uns von einer Migration abraten?

Achtet auch darauf, wie jemand arbeitet. Kleine Pull Requests mit klaren Beschreibungen, Tests für jede Änderung und Kommentare im Review, die erklären statt belehren. Mit dem Kennenlernpaket seht Sie das in einem echten Sprint, bevor Sie Sie länger bindet.