TypeScript ist meine Hauptsprache. Mit der Zeit wurde es für mich mehr als eine Sprachentscheidung: Es steht für bestimmte Werte. Keine Regeln aus einem Styleguide, sondern Gewohnheiten, die bestimmen, ob sich eine Codebasis nach zwei Jahren und drei neuen Entwicklern noch angenehm ändern lässt.
Ehrlichkeit vor Bequemlichkeit. Strict Mode ist ab dem ersten Commit aktiviert. any ist ein Fehlerhinweis, kein Typ; kenne ich die Datenform wirklich nicht, verwende ich unknown und grenze den Typ schrittweise ein. Ein lügender Typ – etwa ein as-Cast, der den Compiler zum Schweigen bringt – ist schlimmer als gar kein Typ, weil alle nachgelagerten Nutzer ihm vertrauen. Beschwert sich der Compiler, hat er meist recht; die Korrektur gehört in die Daten, nicht in die Annotation.
Unmögliche Zustände sollen unmöglich sein. Statt isLoading, isError und data als drei Flags zu führen, die einander widersprechen können, verwende ich eine diskriminierte Union: idle, loading, success mit Daten und error mit Begründung. Dasselbe gilt für Domänenzustände: Eine bezahlte Bestellung hat eine paymentId, eine unbezahlte nicht. Ein switch mit vollständiger never-Prüfung macht aus „Wir haben einen Fall vergessen“ eine rote Markierung im Editor statt eines Produktionsvorfalls.
Im Inneren vertrauen, an den Grenzen prüfen. Typen verschwinden zur Laufzeit. Deshalb wird alles, was eine Systemgrenze überschreitet – HTTP-Body, Webhook, Formular, localStorage oder LLM-Antwort –, mit Zod oder einem ähnlichen Schema geparst; der Typ wird aus diesem Schema abgeleitet. Eine einzige Wahrheitsquelle verhindert Abweichungen zwischen Validierung und Annahmen. Innerhalb der Anwendung fließen typisierte Daten ohne defensive Prüfung auf jeder Zeile.
Verträge teilen, nicht Vermutungen. In einem Full-Stack-Produkt werden API-Typen generiert oder gemeinsam genutzt – aus OpenAPI, GraphQL Codegen, Prisma oder einem gemeinsamen Paket. So lässt ein umbenanntes Feld den Build scheitern, nicht den Checkout. Lesbarkeit schlägt Cleverness: Ein einfaches Interface, das ein neuer Mitarbeiter in zehn Sekunden versteht, ist wertvoller als ein fünfstufiger Conditional Type als Beweis, dass ich das Handbuch gelesen habe. Generics sind für Wiederverwendung da, nicht zum Angeben.
Typen ersetzen weder Tests und Reviews noch Denken – sie machen alles drei günstiger. Darin liegt der wahre Wert eines TypeScript-Entwicklers: nicht jeden Utility Type zu kennen, sondern Code zu hinterlassen, den die nächste Person sicher ändern kann. Ist Ihre Codebasis voller any und hat das Team Angst vor Refactoring, schicken Sie mir das Modul, das niemand anfassen möchte. Ich zeige, wie ich es typisieren würde und welche Fehler dadurch auffallen.
Geben Sie dem nächsten Produkt jemanden, der bleibt.
Bereit für den Start? Schreiben Sie mir – ich kann sofort beginnen und bleiben. Langfristige Mandate statt Übergabe nach zwei Wochen. Lassen Sie uns über Ihr Projekt, die Anforderungen und den besten Weg nach vorn sprechen.