Ergebnis dieses Guides
Eine Funktion mit eindeutigem Vertrag
Arbeitsumgebung
TypeScript mit projektbezogener tsconfig und der vorgesehenen JavaScript-Laufzeit
Wann ist diese Entscheidung wichtig?
Eine Funktion sollte aus ihren Parametern und ihrem Rückgabewert verständlich werden. Versteckte globale Abhängigkeiten erschweren Tests und Wiederverwendung.
Beschreiben Sie interne Verträge möglichst genau und halten Sie unbekannte externe Werte zunächst als unknown. Eine Typbehauptung prüft keine Netzwerkantwort. Die fertige Ausgabe läuft weiterhin unter den Regeln der gewählten JavaScript-Umgebung.
Funktionen: Schritt für Schritt.
- 01
Vorbereiten
Beschreiben Sie Eingaben, Ergebnis und Fehlerfall in einem Satz. Bestimmen Sie, ob ein Seiteneffekt wirklich zur Aufgabe gehört.
- 02
In TypeScript umsetzen
Implementieren Sie eine kleine Funktion und testen Sie Grenzwerte getrennt von Netzwerk oder Datenbank.
- 03
Im tatsächlichen Projekt prüfen
Prüfen Sie sowohl die Typen mit dem Projektcompiler als auch das tatsächliche Laufzeitverhalten. Ein erfolgreicher Typcheck ersetzt keine Eingabeprüfung und keinen Berechtigungstest.
Beispiel zur Überprüfung
So lässt sich das Ergebnis prüfen.
Als Projektkontext dient eine Webanwendung mit mehreren Formularen und API-Antworten. Der folgende Prüffall ist eine Vorlage für diese Aufgabe und kein Bericht über eine Kundenmessung.
- Eingabe / Auslöser
- Eine normalisierte E-Mail-Adresse und ein leerer Eingabewert
- Erwartetes Ergebnis
- Die Funktion liefert einen dokumentierten Wert oder einen ausdrücklich behandelten Fehler.
- Fehler- oder Grenzfall
- Ein Aufruf verändert keine unbeteiligten Daten oder globalen Einstellungen.
TypeScript · begrenztes Beispiel
function total(values: readonly number[]): number {
return values.reduce((sum, value) => sum + value, 0);
}
const budget = total([500, 750, 250]);Parameter und Ergebnis haben einen ausdrücklich benannten Typ. Externe Werte müssen vor dem Aufruf geprüft werden; readonly schützt diese Referenz vor Änderungen durch die Funktion, ist aber keine tiefe Laufzeitsperre.
Abnahme und typische Fehler.
- Jede Funktion lässt sich mit konkreten Fällen prüfen.
- Ein Aufruf verändert keine unbeteiligten Daten oder globalen Einstellungen.
- Typen werden zur Laufzeit entfernt; externe Daten müssen trotzdem validiert werden.
Typischer Fehler
Eine Funktion mit vielen versteckten Nebenwirkungen ist schwer wartbar.
Quellen und Versionshinweis
Die Anleitung beschreibt das Vorgehen; konkrete APIs, Produktfunktionen und Laufzeitgrenzen müssen zur eingesetzten Version passen. Halten Sie Version, Konfiguration und Prüfergebnis im Projekt fest und vergleichen Sie die verlinkte Dokumentation bei Änderungen.
