„Funktioniert — nicht anfassen“ — was es ist, Wesen des Prinzips und Risiken

Was ist das Prinzip „Funktioniert — nicht anfassen“?

„Funktioniert — nicht anfassen“ — eine empirische Regel, die Entwickler davor warnt, Änderungen an funktionierendem Code ohne ausreichende Gründe vorzunehmen. Das Prinzip basiert auf einfacher Statistik: Die allermeisten Fehler werden bei der Modifikation vorhandenen Codes eingeführt.

Das Prinzip ist kein Dogma — es ist eher eine Heuristik, die hilft, Entscheidungen unter Unsicherheit zu treffen. Je komplexer und verworrener die Codebasis, desto höher ist die Wahrscheinlichkeit, dass eine „unschuldige“ Änderung etwas kaputt macht, mit dem niemand gerechnet hat.

Laut einer Studie von Microsoft Corporation (2024) stehen etwa 60% aller kritischen Vorfälle in der Produktion im Zusammenhang mit kürzlichen Codeänderungen, die in guter Absicht vorgenommen wurden, aber unter realen Lastbedingungen nicht ausreichend getestet wurden.

Geschichte und Ursprung des Prinzips

Die Redewendung „If it ain’t broke, don’t fix it“ geht zurück auf die amerikanische Ingenieurskultur der Mitte des 20. Jahrhunderts. Die früheste dokumentierte Verwendung wird Bert Lance (1977) zugeschrieben, der im Finanzausschuss des US-Senats arbeitete und sich gegen übermäßige Regulierung aussprach.

In der Programmierung kam das Prinzip aus der Hardwaretechnik, wo der Austausch eines funktionierenden Chips durch einen neuen zu unvorhersehbaren Folgen führen konnte. Im Kontext von Software gewann dieses Prinzip mit der zunehmenden Komplexität von Softwaresystemen und dem Aufkommen von Legacy-Code besondere Verbreitung.

Interessanterweise hat das Prinzip in der Programmierung auch eine Kehrseite — „es funktioniert, aber besser nicht anfassen“ wird oft zur Ausrede, um Refactoring zu vermeiden, was langfristig zu einer kritischen Anhäufung von technischen Schulden führt. Laut der Beratungsfirma Thoughtworks (2023) haben etwa 40% der Projekte aufgrund von übermäßigem Konservatismus gegenüber Änderungen ernsthafte Probleme.

Wann das Prinzip anwenden

Das Prinzip „Funktioniert — nicht anfassen“ ist besonders in Situationen relevant, in denen die Kosten eines Fehlers den potenziellen Nutzen von Änderungen übersteigen.

Legacy-Projekte ohne Tests

In Legacy-Code, der nicht durch Tests abgedeckt ist, ist jede Änderung ein russisches Roulette. Wenn ein Entwickler nicht überprüfen kann, ob die Änderung benachbarte Module nicht beschädigt hat, ist die beste Strategie, den funktionierenden Code nicht anzufassen. Die Ausnahme sind nur kritische Fehler oder Sicherheitsanforderungen.

Kritische Systeme

In Systemen, in denen Ausfallzeiten inakzeptabel sind oder die Kosten eines Fehlers enorm sind — medizinische Software, Avionik, Finanztransaktionen — ist das Prinzip „Funktioniert — nicht anfassen“ der De-facto-Standard. Jede Änderung durchläuft eine mehrstufige Genehmigung und Tests.

Knappe Fristen

Wenn der Release morgen ist und der Code funktioniert — versuchen Sie nicht, seine Architektur zu verbessern. Ändern Sie nur das, was direkt die Funktionalität des Releases beeinflusst. Verschieben Sie das Refactoring auf den nächsten Sprint (aber vergessen Sie es nicht).

Risiken der Befolgung des Prinzips

Blinde Befolgung des Prinzips „Funktioniert — nicht anfassen“ birgt nicht geringere Risiken als endloses Refactoring. Betrachten wir die wichtigsten Gefahren.

Anhäufung technischer Schulden

Wenn jeder Entwickler diesem Prinzip folgt, wird die Codebase schnell zu einem „Schichtkuchen“ aus veralteten Lösungen, Workarounds und suboptimalen Algorithmen. Früher oder später werden die technischen Schulden untragbar — jede Änderung erfordert Wochen der Analyse.

Verpasste Optimierung

Manchmal verbessert eine Änderung, die riskant erscheint, tatsächlich die Leistung oder Sicherheit erheblich. Das Prinzip „Funktioniert — nicht anfassen“ sollte keine Änderungen blockieren, die messbare Vorteile bringen — Serverkosten senken, Seitenladezeiten beschleunigen, Sicherheit erhöhen.

Kompetenzverlust

Wenn ein Team bestimmte Codebereiche jahrelang nicht anfasst, verliert es das Verständnis dafür, wie sie funktionieren. Der wichtige Entwickler geht — und der Code wird zu Legacy ohne Wartungsmöglichkeit. Das Prinzip sollte unter Berücksichtigung der langfristigen Wartbarkeit des Projekts angewendet werden.

Die goldene Mitte: Refactoring ohne Fanatismus

Die optimale Strategie ist, das Prinzip nicht blind zu befolgen, sondern es bewusst und kontextbezogen anzuwenden. Refactoring ist notwendig, aber es muss sicher sein.

Die Pfadfinderregel

Die Pfadfinderregel in der Programmierung: „Hinterlasse den Code sauberer, als du ihn vorgefunden hast.“ Wenn ein Entwickler eine Änderung an einem Modul vornimmt, sollte er dessen Struktur verbessern, aber in vernünftigen Grenzen. Nicht alles von Grund auf neu schreiben, sondern zumindest unlesbare Variablen umbenennen und Kommentare hinzufügen.

Refactoring unter Testschutz

Tests sind die einzige Möglichkeit, das Prinzip „Funktioniert — nicht anfassen“ sicher anzuwenden. Wenn der Code durch Tests abgedeckt ist, wird jedes Refactoring vorhersagbar: Der Entwickler ändert den Code, führt die Tests aus und sieht, ob etwas kaputt gegangen ist. Ohne Tests — nicht anfassen. Mit Tests — refactorn Sie zuversichtlich.

// Beispiel: Sicheres Refactoring unter Testabdeckung
class PriceCalculator {
    fun calculatePrice(basePrice: Double, discount: Double): Double {
        // Alter, aber funktionierender Code
        return basePrice - (basePrice * discount / 100.0)
    }
}

// Test, der vor Regression schützt
class PriceCalculatorTest {
    fun testCalculatePrice() {
        val calc = PriceCalculator()
        assertEquals(90.0, calc.calculatePrice(100.0, 10.0))
    }
}

Dieses Beispiel zeigt den richtigen Ansatz: zuerst der Test, dann das Refactoring. Wenn der Test bestanden wird, ist die Änderung sicher. Das Prinzip „Funktioniert — nicht anfassen“ verwandelt sich in „Funktioniert unter Tests — refactorn Sie mutig.“

Praktische Beispiele aus der Praxis

Betrachten wir reale Szenarien, in denen sich das Prinzip „Funktioniert — nicht anfassen“ sowohl als rettend als auch als zerstörerisch erwiesen hat.

Rettender Fall: Y2K-ähnliches Problem

Ein Entwickler entdeckte, dass der Datumsverarbeitungscode das Format DD/MM/YY statt YYYY verwendete. Der Code funktionierte von 2000 bis 2025 korrekt. Trotz des Wunsches, es zu „beheben“, ließ er den Code wie er war und beschränkte sich auf einen Kommentar. 2026 aktualisierte das Unternehmen das System, und die neue Lösung verarbeitete Jahrhunderte korrekt. Eine vorzeitige Änderung hätte die funktionierende Logik zerstört.

Zerstörerischer Fall: Datenverlust durch „Verbesserung“

Ein Ingenieur beschloss, den alten, aber funktionierenden Datenimportcode zu „verbessern“, indem er ihn durch eine moderne Bibliothek ersetzte. Er berücksichtigte nicht, dass die alte Bibliothek einen spezifischen Randfall behandelte, der nicht dokumentiert war. Nach dem Release — massiver Datenverlust. Das Prinzip „Funktioniert — nicht anfassen“ wurde verletzt, und die Kosten des Fehlers betrugen zwei Wochen Teamarbeit zur Wiederherstellung.