Feature Toggle Dynamics in Large-Scale Systems: Prevalence, Growth, Lifespan, and Benchmarking
Die Studie analysiert die Dynamik von Feature-Toggles in den großen Open-Source-Projekten Kubernetes und GitLab, zeigt deren übermäßiges Wachstum und lange Lebensdauer auf und schlägt darauf aufbauend einen Benchmarking-Rahmen mit fünf Metriken zur Bewertung des Toggle-Managements vor.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich vor, Sie bauen ein riesiges, komplexes Haus – sagen wir, einen Wolkenkratzer, der ständig umgebaut wird. In diesem Haus gibt es eine spezielle Art von Schaltern: Feature-Toggles.
Diese Schalter sind wie magische Lichtschalter, die man nicht nur an- und ausschalten kann, sondern die auch unsichtbare Wände im Haus verschieben können. Ein Entwickler schaltet einen Schalter um, und plötzlich ist ein neuer Raum (eine neue Funktion) für die Besucher sichtbar, ohne dass man das ganze Haus neu bauen oder die Stromleitung unterbrechen muss. Das ist genial für schnelle Updates und Experimente.
Aber hier kommt das Problem: Diese Schalter werden oft vergessen.
Das Problem: Der Schalter, der nie ausgeht
Stellen Sie sich vor, Sie bauen einen neuen Spielplatz in Ihrem Garten. Sie installieren einen temporären Zaun (den Schalter), um zu testen, ob die Kinder ihn mögen. Wenn der Spielplatz fertig ist, sollte der Zaun weg. Aber oft passiert Folgendes: Der Zaun steht noch da, niemand weiß mehr, wozu er dient, und nach Jahren ist er zu einem festen Teil des Gartens geworden.
In der Software-Welt nennt man das technische Schulden. Jeder vergessene Schalter macht den Code (das Haus) unübersichtlicher, schwerer zu reparieren und gefährlicher für neue Fehler.
Was haben die Forscher untersucht?
Die Autoren dieser Studie haben sich zwei riesige "Häuser" genauer angesehen:
- Kubernetes: Ein riesiges System, das wie ein Dirigent für tausende Container-Server funktioniert (geschrieben in Go).
- GitLab: Eine große Plattform für Software-Entwickler (geschrieben in Ruby).
Sie haben sich über Jahre hinweg die Geschichte dieser Systeme angesehen – quasi wie einen Tagebuch-Eintrag für jeden einzelnen Schalter, der je eingebaut oder entfernt wurde. Insgesamt haben sie über 4.000 dieser Ereignisse analysiert.
Die wichtigsten Entdeckungen (in einfachen Worten)
1. Die Schalter häufen sich an
In beiden Systemen wurden mehr Schalter eingebaut als entfernt.
- Bei Kubernetes kamen pro Monat etwa 35 % mehr Schalter hinzu, als weggingen.
- Bei GitLab waren es immerhin noch 13 %.
Das bedeutet: Der "Zaun" im Garten wächst langsam, aber stetig. Niemand räumt wirklich auf.
2. Die Lebensdauer ist unterschiedlich
Wie lange bleibt ein Schalter eigentlich an?
- In Kubernetes bleiben Schalter im Durchschnitt fast zwei Jahre (734 Tage) aktiv. Das ist wie ein Schalter, der jahrelang leuchtet, nur um sicherzugehen.
- In GitLab gehen sie viel schneller aus – im Durchschnitt nach sechs Monaten (185 Tage).
Das zeigt: Verschiedene Teams haben ganz unterschiedliche Gewohnheiten. Was für das eine Team "normal" ist, ist für das andere schon "veraltet".
3. Die "Unsterblichen"
Das Beunruhigendste: Ein kleiner Teil der Schalter (etwa 1 % in beiden Systemen) wird nie ausgeschaltet. Sie haben ihre geplante Lebensdauer längst überschritten und sind zu dauerhaften Einrichtungsgegenständen geworden.
- Ein Beispiel in Kubernetes: Ein Schalter, der seit 2019 (über 6 Jahre!) aktiv ist, obwohl er längst hätte entfernt werden sollen.
Das ist, als würde man einen provisorischen Bauzaun aus dem Jahr 2019 immer noch im Garten stehen haben, obwohl das Haus fertig ist.
Die Lösung: Ein "Gesundheits-Check" für Schalter
Da die Forscher gemerkt haben, dass es keine klaren Regeln gibt, wann ein Schalter "zu alt" ist, haben sie ein Benchmarking-System (einen Maßstab) entwickelt.
Stellen Sie sich das wie einen Fitness-Test für Software vor. Sie können Ihren eigenen Code messen und vergleichen:
- Wie viele Schalter haben wir? (Dichte)
- Wie schnell bauen wir neue und wie schnell räumen wir auf? (Churn-Rate)
- Wie lange bleiben sie durchschnittlich an? (Lebensdauer)
Sie haben sogar eine Farb-Skala erstellt:
- Grün: Alles okay, wir räumen gut auf.
- Gelb: Vorsicht, es häufen sich ein paar alte Schalter an.
- Rot: Alarm! Wir haben zu viele vergessene Schalter, das Haus wird unübersichtlich.
Warum ist das wichtig?
Ohne solche Regeln bauen Teams versehentlich ein Labyrinth aus vergessenen Schaltern auf. Das macht die Software langsam, teuer zu warten und anfällig für Fehler.
Die Studie sagt uns: Es gibt nicht die eine richtige Art, mit Schaltern umzugehen. Ein Team kann viele, kurzlebige Schalter haben (wie GitLab), ein anderes wenige, langlebige (wie Kubernetes). Wichtig ist nur, dass man weiß, wie es bei einem selbst aussieht, und dass man aktiv aufräumt, bevor die "technischen Schulden" das ganze Haus zum Einsturz bringen.
Kurz gesagt: Feature-Toggles sind super Werkzeuge, aber wie bei Werkzeugen im Keller: Wenn man sie nie wegräumt, wird der Keller voll, und man findet nichts mehr. Diese Studie gibt uns eine Liste, damit wir wissen, wann es Zeit ist, den Keller zu entrümpeln.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.