Feature-Flag-Software ist überbewertet: Warum Hardcoding oft die beste Wahl ist
It's OK to hardcode feature flags (2025)
Feature-Flags lassen sich auf viele Arten implementieren, doch die meiste Aufmerksamkeit genießt spezielle Verwaltungssoftware. Dieser Artikel argumentiert, dass diese Systeme oft unnötige Komplexität und Risiken mit sich bringen – von nicht-deterministischem Verhalten bis zu erhöhter Angriffsfläche. Der Autor plädiert für den simpelsten Ansatz: Flags direkt im Code zu definieren, etwa über eine JSON-Datei, die beim Start gelesen wird. Das sei zuverlässig, sicher und leicht zu pflegen. Für die meisten Teams reiche das völlig aus; erst wenn man tatsächlich Features zur Laufzeit in großem Maßstab umschalten müsse, sei spezielle Software gerechtfertigt.
Hardcoded Feature Flags sind die langweiligste Art, es zu tun, und genau deshalb sind sie die beste Art, es zu tun.
- jameshart
Meiner Erfahrung nach sind das (konfigurationsbasierte Feature-Flags und Feature-Flag-Dienste) eigentlich zwei sich ergänzende Fähigkeiten, die zwei völlig unterschiedliche Probleme lösen, aber zufällig denselben Namen teilen: Feature-Flags.
Der Konfigurationsansatz ist entscheidend für die Nutzung von Feature-Flags als Werkzeug im Softwareentwicklungslebenszyklus. Damit verwaltet man eine Codebasis, die den unfertigen Code für das neue Feature x enthält, aber trotzdem bereitgestellt werden und alle Tests bestehen kann, ohne dass Feature x aktiviert ist.
In diesem Modell braucht man einen Mechanismus, der es einem Entwickler, der an Feature x arbeitet, ermöglicht, es für lokale Tests zu aktivieren, und der es dem CI-System erlaubt, mit dem Flag-System zu interagieren, um zu testen, dass die Anwendung in beiden Zuständen funktioniert – mit x ein- und ausgeschaltet.
Das ist ideal für trunk-basierte Entwicklungsmodelle; Feature-Branches sind ein alternativer Ansatz, der davon nicht wirklich profitiert (tatsächlich fügt es der Arbeit in Feature-Branches Komplexität hinzu).
In der Zwischenzeit lösen Feature-Flag-Dienste das Problem, dass verschiedene Benutzer, die dieselbe Software verwenden, unterschiedliche Features aktiviert haben müssen. Das kann so einfach sein wie interne Tester oder Beta-Benutzer, es kann das Zurückhalten von Features für feste Update-Fenster pro Mandant sein, oder es kann Teil einer Risikomanagementstrategie sein, bei der Features durch progressive Exposition ausgerollt werden.
Es kann auch verlockend sein, sein Feature-Flag-System mit einem A/B-Testsystem zu vermischen – man kann einen Feature-Flag-Dienst verwenden, um ein Feature einer Testkohorte zugänglich zu machen und […]
- jdwyah
Ich bin bei meinem zweiten Feature-Flag-Startup, aber ich stimme dem auch teilweise zu.
Jedes Projekt sollte Flags haben, aber viele Projekte brauchen nur das Nötigste und ein Dienst ist übertrieben.
Sich sein eigenes JSON zu basteln, fühlt sich trotzdem wie etwas an, das wir vermeiden sollten. Ja, am Anfang sind es 95 % Booleans. Aber dann will man einen Rollout. Und dann will man einige Targeting-Regeln. Und dann will man Nicht-Booleans … vielleicht etwas JSON. Oh, wäre es nicht schön, wenn das JSON einem Schema entsprechen könnte … und schließlich ist man wie: Verdammt, ich möchte diese wirklich ohne Deployment ändern. Oder man möchte dasselbe Flag aus mehreren Diensten lesen.
Ich habe versucht, diesen kleinsten gemeinsamen Nenner in https://quonfig.com einzubauen. Nutzen Sie es völlig kostenlos und Open Source als SDK, und es lädt einfach JSON, das Sie in Git verfolgen können. Agenten lieben es, Hot Reloads, SDK in vielen Sprachen. Aber im Vergleich zu selbst gebauten Sachen hat man viel Spielraum beim Design. Eine Reihe von Targeting-Operatoren. Segmente usw. Und wenn man dann eine schöne Benutzeroberfläche / ein Liefernetzwerk für Echtzeit-Updates haben möchte, kann man die kostenpflichtige Seite der Dinge nutzen.
Lokale Nutzungsbeschreibung: https://docs.quonfig.com/docs/how-tos/open-source-local
- avlcodemonkey
Wenn Sie mit C# arbeiten, hat Microsoft erstklassige Unterstützung für Feature-Management in .Net hinzugefügt, mit https://github.com/microsoft/featuremanagement-dotnet. Es bietet die Logik für einfaches Ein/Aus, Benutzer-Targeting, prozentuale Rollouts und Zeitpläne. Die Verwendung von Feature-Management zusammen mit in `appSettings.json` hartcodierten Flags ergibt für eine einfachere Anwendung absolut Sinn.
Wenn Ihre Architektur wächst und Sie beginnen, Konfiguration über mehrere Anwendungen hinweg zu synchronisieren, oder nicht-technische Benutzer Flags ändern müssen, dann haben Sie das Hardcoding wahrscheinlich überholt und müssen in Betracht ziehen, einen Dienst zu bauen (oder zu kaufen). Sie möchten wahrscheinlich nicht, dass Produktverantwortliche versuchen, eine Umgebungsvariable wie `FeatureManagement__NewFeature__EnabledFor__0__Name` zu setzen. Azure App Configuration ist die erste Wahl, wenn Sie bereit sind, Azure zu nutzen – es bietet eine schöne Benutzeroberfläche zum Bearbeiten von Flags, anstatt sich mit JSON herumzuschlagen. Oder ich habe https://featureflags.app/ als alternativen Anbieter gebaut, wenn Sie Azure lieber meiden möchten. Es ist sozusagen der Mittelweg zwischen Hardcoding und einer vollwertigen Plattform wie LaunchDarkly.
- maxidog
Ich reverse-engineere gerade eine große Unternehmensanwendung und die Feature-Flag-Aufblähung ist wirklich erstaunlich. Meiner bescheidenen Meinung nach ist übermäßige Feature-Flag-Komplexität ein Symptom für Management, das unentschlossen ist und dem die Entwickler nicht vertrauen.
- stronglikedan
Es sei denn, Sie sind natürlich Knight Capital. https://www.youtube.com/watch?v=UuqSy1jPSUw