Regel

Behalten Sie Funktionen prägnant.
Lange Funktionen sind schwierig zu verstehen, testen, und warten.

Unterstützte Sprachen: 45+

Einleitung

Funktionen, die Hunderte von Zeilen umfassen, vermischen mehrere Verantwortlichkeiten, was es schwierig macht, die Funktion zu verstehen, ohne jede Zeile zu lesen. Lange Funktionen behandeln typischerweise mehrere Anliegen wie Validierung, Geschäftslogik, Datentransformation und Fehlerbehandlung an einem Ort. Dies verletzt das Single Responsibility Principle und erzeugt Code, der schwer zu testen, zu debuggen und zu ändern ist, ohne bestehendes Verhalten zu beeinträchtigen.

Warum es wichtig ist

Code-Wartbarkeit: Lange Funktionen erfordern von Entwickelnde, mehr Kontext im Kopf zu behalten, um das Verhalten zu verstehen. Die Änderung eines Teils birgt das Risiko, einen anderen zu beschädigen, da die gesamte Logik miteinander verknüpft ist. Fehlerbehebungen werden riskant, da unbeabsichtigte Nebenwirkungen schwer vorhersehbar sind.

Testkomplexität: Das Testen einer 200-zeiligen Funktion bedeutet, alle möglichen Codepfade in einem Test abzudecken, was einen komplexen Aufbau und zahlreiche Testfälle erfordert. Kleinere Funktionen können unabhängig mit fokussierten Unit-Tests getestet werden, was Test-Suites schneller und zuverlässiger macht.

Code-Beispiele

❌ Nicht konform:

async function processOrder(orderData) {
    if (!orderData.items?.length) throw new Error('Items required');
    if (!orderData.customer?.email) throw new Error('Email required');
    const subtotal = orderData.items.reduce((sum, item) => 
        sum + (item.price * item.quantity), 0);
    const tax = subtotal * 0.08;
    const total = subtotal + tax + (subtotal > 50 ? 0 : 9.99);
    const order = await db.orders.create({
        customerId: orderData.customer.id,
        total: total
    });
    await emailService.send(orderData.customer.email, `Order #${order.id}`);
    await inventory.reserve(orderData.items);
    return order;
}

Warum es falsch ist: Diese Funktion verarbeitet Validierung, Berechnung, Datenbankoperationen, E-Mail und Inventar. Das Testen erfordert das Mocken aller Abhängigkeiten. Jede Änderung an der Steuerlogik oder Validierung erfordert eine Modifikation dieser gesamten Funktion.

✅ Konform:

function validateOrder(orderData) {
    if (!orderData.items?.length) throw new Error('Items required');
    if (!orderData.customer?.email) throw new Error('Email required');
}

function calculateTotal(items) {
    const subtotal = items.reduce((sum, item) => 
        sum + (item.price * item.quantity), 0);
    return subtotal + (subtotal * 0.08) + (subtotal > 50 ? 0 : 9.99);
}

async function createOrder(customerId, total) {
    return await db.orders.create({ customerId, total });
}

async function processOrder(orderData) {
    validateOrder(orderData);
    const total = calculateTotal(orderData.items);
    const order = await createOrder(orderData.customer.id, total);
    
    // Non-critical operations in background
    emailService.send(orderData.customer.email, `Order #${order.id}`).catch(console.error);
    
    return order;
}

Warum dies wichtig ist: Jede Funktion hat eine klare Verantwortung. validateOrder() und calculateTotal() kann unabhängig ohne Mocks getestet werden. createOrder() isoliert die Datenbanklogik. E-Mail- und Bestandsoperationen blockieren die Auftragserstellung nicht, und Fehler werden separat behandelt.

Fazit

APIs durch additive Änderungen weiterentwickeln: neue Felder, neue Endpunkte und optionale Parameter hinzufügen. Wenn Breaking Changes unvermeidlich sind, API-Versionierung nutzen, um alte und neue Versionen gleichzeitig zu betreiben. Alte Felder mit klaren Zeitplänen und Migrationsleitfäden als veraltet kennzeichnen, bevor sie entfernt werden.