Zum Inhalt springen
Startseite » Blog » Was bedeutet „fail fast“ in der Softwareentwicklung?

Was bedeutet „fail fast“ in der Softwareentwicklung?

Ist Dir im Bereich der Softwareentwicklung schon einmal der Begriff „fail fast“ über den Weg gelaufen? Bestimmt. Neben all den bekannten Entwicklungsprinzipien wie z. B. SOLID, YAGNI, IOSP usw. ist „fail fast“ eines der weniger bekannten – aber es ist deswegen nicht weniger wichtig. Im Gegenteil: „Fail fast“ ist für mich eines der wichtigsten Prinzipien in der Softwareentwicklung. In diesem Artikel zeige ich Dir, warum.

„Fail fast“ – was bedeutet das?

„Fail fast“ kommt aus dem Englischen und bedeutet wörtlich übersetzt „schnell scheitern“. Hierbei geht es nicht um unsere Karriere in der Softwareentwicklung :-). Wir wollen nicht in unserem Beruf schnell scheitern, sondern wir möchten, dass Programmierfehler und Bugs schnell sichtbar werden. Wenn unsere Software einen Fehler enthält, möchten wir diesen möglichst früh erkennen. Warum ist das wichtig?

Wenn Fehler zu spät auffallen – eine kleine Geschichte

Ich betreue nebenbei einige Softwareprojekte. Darunter auch welche, deren Codequalität nicht die beste ist, und die außerdem keine Unit-Tests und Integrationstests beinhalten. Es ist kein Legacycode, aber so ähnlich …

In einem Laravel-Projekt habe ich vor einigen Tagen neue Programmbibliotheken hinzugefügt. Dabei wurde auch automatisch eine andere Bibliothek von Version 3.0.x auf 3.4.1 aktualisiert. Gemäß dem Semantic Versioning sollte das kein Problem darstellen, wenn die Minor-Version einer Bibliothek hochgezogen wird (hier von .0 auf .4), denn es dürfen nur abwärtskompatible Änderungen eingeführt werden.

Leider ist dem Entwickler der Bibliothek nicht aufgefallen, dass er doch einen Breaking Change eingeführt hat. Die Bibliothek erwartet nun nämlich einen weiteren Konfigurationswert und es gibt keinen Defaultwert dafür. Wenn der Konfigurationswert nicht vorhanden ist, bricht sie mit einem Fehler ab.

Und genau das ist passiert. Mehrmals. Im Live-Betrieb. Weil es bei den manuellen Tests vor dem Rollout nicht aufgefallen war. Toll.

In diesem Prozess ist einiges schiefgelaufen:

  1. Da nur die Minor-Version hochgezogen wurde, ging ich davon aus, dass die entsprechende Komponente nicht durchgetestet werden muss.
  2. Das Budget des Projektes ist begrenzt, so dass vor einem Rollout kein manueller Test mit 100 % Prozessabdeckung durchgeführt werden kann.
  3. Es gibt keine Unit- oder Integrationstests
  4. Weder im Projekt noch in der Bibliothek wurde auf „fail fast“ geachtet

Wenn in dem Projekt und in der Bibliothek „fail fast“ implementiert wäre, wäre beim ersten Test aufgefallen, dass ein Konfigurationswert fehlt. Ich hätte keine Seite des Projektes im Testsystem aufrufen können und keinen Kommandozeilen-Befehl ausführen können. Ich hätte sofort gemerkt, dass etwas nicht passt und nicht erst Tage nach dem Rollout.

„fail fast“ – Laravel und Symfony verfolgen unterschiedliche Ansätze

Bei Laravel-Projekten sind die Konfigurationswerte meist als einfaches PHP-Array in PHP-Dateien abgespeichert (siehe Laravel Konfiguration). Diese Werte werden abgerufen und validiert wenn sie gebraucht werden. Das kann irgendwo und irgendwann tief im Benutzerprozess sein. Vorher ist schon viel passiert. Vielleicht wurde schon eine Reservierung begonnen, ein Bezahlprozess initiiert oder irgendwas anderes vorbereitet, bis dem System auffällt: „Hoppla, da fehlt ja etwas in der Konfiguration“.

In Symfony-Projekten mit einer hohen Code-Qualität funktioniert das etwas anders. Hier kann man mit Hilfe der Config-Komponente genau definieren, welche Konfigurationswerte benötigt werden und welche Werte zulässig sind.

Hier kommt „fail fast“ ins Spiel, denn die Validierung der gesamten Konfiguration geschieht bereits beim Start der Applikation. Selbst wenn der Konfigurationswert erst spät im Prozess benötigt wird, wird bereits beim Start (bei Web-Applikationen: zu Beginn der Abarbeitung des Requests), die Konfiguration validiert. Wenn Konfigurationswerte fehlen, fällt das sofort auf. Man kann dann nämlich kein Konsolenkommando und keinen Web-Request ausführen. Es kommt sofort eine Fehlermeldung. DAS ist „fail fast“.

Wie denkst Du über „fail fast“?

Ist „fail fast“ ein Prinzip, dass Du selbst anwendest? Wie wendest Du es an? Hast Du dich für ein bestimmtes Framework entschieden, weil dort vieles „fail fast“-optimiert ist? Schreib das doch einfach in die Kommentare.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

WordPress Cookie Hinweis von Real Cookie Banner