Er schildert recht anschaulich die Anwendungsgebiete und auch die Vor- und Nachteile, die Feature Toggles mit sich bringen.
Ich glaube mich zu erinnern, dass @maki mal erwähnt hat, dass er beruflich mit Featuretoggles arbeitet.
Wie sind eure praktischen Erfahrungen?
Persönlich stehe ich vor der Herausforderung, dass das Entwicklerteam, welches ggf. mit Feature Toggles arbeiten soll, vom Erfahrungsschatz her sehr durchmischt ist. Auf der anderen Seite gibt es aber auch einen QA-Prozess, der es ggf. erfordert, dass ein Feature kurzfristig doch nicht produktiv gehen darf.
Wir benutzen Feature Toggles in unserem „alten“ Produkt, mit durchmischten Ergebnissen. Im „neuen“ Produkt gibt es diese nur, wenn kundenspezifische Gründe vorliegen (also ein Kunde z.B. ein bestimmtes Verhalten abschalten können will), von Entwicklungsseite sollen stattdessen Integration-Branches verwendet werden (die ihre eigenen Probleme haben).
Meine Sicht ist:
Feature Toggles sind nicht „umsonst“ zu haben, man sollte sich bewusst mit den Kosten auseinandersetzen
Bei neuen Features kann man eventuell stattdessen ein austauschbares Modul verwenden (z.B. via SPI)
das Feature muss klar umrissen sein, es darf zwischen verschiedenen Features keine Abhängigkeiten geben (Orthogonalität)
die Anzahl Codestellen, die das Flag abfragen, soll natürlich minimiert werden
wenn man sich prinzipiell für die Verwendung entscheidet, sollte eine entsprechende Infrastruktur geschaffen werden, die z.B. Testbarkeit sicherstellt
In diesem Projekt haben wir einen wöchentlichen Releasezyklus und es kommt immer wieder vor, dass ein Feature nicht produktiv gehen soll. Außerdem sollen etwa 50% der Features bis zur vollständigen Einführung abschaltbar sein. Wir arbeiten derzeit mit Feature- und Integrationbranches.
Der Releasezyklus mit dem Erfordernis kurzfristig ein Feature auszuschalten sprechen aus meiner Sicht stark für Feature Toggles. Dass dabei Kosten entstehen ist mir bewusst.
Das größte Risiko sehe ich in den Fertigkeiten der Entwickler. Im Team sind auch Juniorentwickler, die sehr wenig Erfahrung haben.
Damit das ganze gut funktioniert, müssen die Features möglichst gut gekapselt implementiert werden (was sie auch ohne Feature Toggles eigentlich sein sollten).
Bekommen auch die Junioren bei euch togglebare Features sinnvoll gebaut?
Wie sieht es denn mit deiner Erfahrung zum Ausbau der Toggles aus? Klappt das bei euch immer „schnell“?
Zum Thema Junior-Entwickler kann ich wenig sagen, da wir keine haben. Aber generell glaube ich nicht, dass das ein Problem sein sollte.
Problematisch werden Feature Toggles erst dann, wenn man 2 Fehler begeht:
Story = Feature. So hatten es wir ganz lange Zeit und ich glaube manche Teams arbeiten noch immer so. Dementsprechend haben wir ziemlich viele davon.
„Fire & Forget“. Gerade das entfernen von Feature-Toggles wird oft gerne vergessen.
An und für sich sind Feature-Toggles eigentlich ne ganz nette Sache. Und wenn etwas mal nicht so richtig implementiert wurde, dann ist ein Feature-Toggle gold wert.
Problematisch wird es vor allem dann, wenn man eine temporäre Lösung plötzlich für immer drin hat. Denn dann schaffst du dir eine zusätzliche Konfiguration die sich von System zu System unterscheiden kann.
Was ein ausschaltbares „Feature“ ist, gibt die Domäne / der Kunde vor - da wird es wenig Gestaltungsspielraum geben. Zum Thema Entfernen der Toggles stellt der eingangs gepostete Artikel einen interessanten Ansatz vor: Toggles mit Verfallsdatum. Ob man das direkt so umsetzen möchte oder lieber nur eine Metrik über das Alter der Toggles hat ist erstmal nebensächlich. Beim initialen Design der Toggles würde ich aber wahrscheinlich direkt das Erstelldatum an den Toggle codieren.
