Verwenden von Feature Toggling und IoC anstelle von Branching Code - gute oder schlechte Idee?

9

Unsere Kunden können wählen, wann sie upgraden möchten. Also muss mein Team buchstäblich Dutzende von Versionen unseres Softwareprodukts warten und unterstützen. Wie Sie sich vorstellen können, führt dies zu vielen Verzweigungen und Zusammenführungen, da Hotfixes und Service Packs über alle diese Varianten verbreitet werden müssen. Ich bin nicht glücklich mit der Situation. Die offensichtliche Lösung besteht einfach darin, nicht so viele verschiedene Versionen unseres Produkts zu erhalten, aber diese offensichtliche Lösung steht mir nicht zur Verfügung. Also erkunde ich kreative Möglichkeiten, um die Wartungsarbeiten des Teams zu reduzieren. Ich erwäge, eine Mischung aus Feature-Toggling und IoC zu verwenden, um mehrere Versionen unseres Softwareprodukts zu implementieren. Die Idee ist, dass ich eine einzige Codebasis für mein Produkt verwenden und Verhaltensweisen und Funktionen über das Konfigurationsmanagement verwalten kann. Dies würde bedeuten, Code über mehrere Zweige hinweg verbreiten zu müssen. Ist das ein vernünftiger Ansatz oder tauge ich nur ein Problem für ein anderes ab?

    
Ed Chaparro 22.03.2012, 02:24
quelle

1 Antwort

3

Das hört sich vernünftig an, weil ich so ein Problem in einer grünen Umgebung angehen würde.

Wir nennen es jedoch nicht Feature Toggle . Wie der Name schon andeutet, ist ein Feature Toggle ein on / off Schalter, was nicht der Fall sein kann was du brauchst.

Manchmal beinhaltet ein Upgrade auch das geänderte Verhalten in bestehenden Funktionen. Das bedeutet, dass Sie wahrscheinlich etwas komplizierteres brauchen werden als einen on / off Schalter.

Das Strategie-Pattern ist eine flexiblere Möglichkeit, Verhaltensänderungen zu modellieren. Jede Strategie kann eine bestimmte Version eines bestimmten Verhaltens darstellen, und wenn Sie das Verhalten überhaupt nicht möchten, können Sie ein Null-Objekt bereitstellen Implementierung. Mit anderen Worten, Feature Toggle kann mit einer Strategie implementiert werden.

Sie können die Strategien mit Dependency Injection in Ihren Anwendungskern einfügen und Sie können die Strategien über ein Konfigurationssystem konfigurieren. Die meisten DI-Container, von denen ich gehört habe (auf .NET und Java), unterstützen die dateibasierte Konfiguration.

Dies beschreibt im Wesentlichen eine Add-in-Architektur .

Nun, selbst für eine Greenfield-Anwendung ist das keine leichte Aufgabe. Wenn Sie ein Headless-System haben, ist es nicht das , aber sobald Sie eine Benutzeroberfläche haben, werden Sie feststellen, dass Sie auch die UI-Architektur komponieren müssen, damit Sie sie anschließen können in UI-Elementen über Strategien.

Auf einer jahrzehntelangen Code-Basis wäre das eine "interessante Herausforderung", um es gelinde auszudrücken.

    
Mark Seemann 01.02.2016 11:46
quelle