![\"\"](\"http:\/\/abramowitsch.de\/blog\/wp-content\/uploads\/2013\/10\/101313_1029_Verwendenvo1.png\")
<\/p>\nBei der professionellen Software-Entwicklung ist eine Versionsverwaltung nicht mehr wegzudenken. Fast alle Versionskontroll-Systeme unterst\u00fctzen Branches, in denen man beispielsweise die Entwicklung von Features vornimmt, um den Code im Hauptzweig (trunk) nicht zu beeinflussen und unabh\u00e4ngig das Feature entwickeln zu k\u00f6nnen:<\/p>\n
<\/p>\n
Hier ist ein Beispiel daf\u00fcr, wie ich bisher die Produkt- \/ Projektentwicklung kannte: Nachdem eine Produkt-Version released wurde, werden Feature-Branches angelegt, um die Features unabh\u00e4ngig vom Entwicklungs-Branch zu entwickeln. Das hat sehr viele Vorteile: Beispielsweise k\u00f6nnte sich das Produktmanagement entscheiden, ein Feature erst in einer sp\u00e4teren Version zu integrieren, falls sich die Entwicklung verz\u00f6gern sollte. Zudem kann die Entwicklung eines Features unabh\u00e4ngig von der Entwicklung anderer Features stattfinden.<\/p>\n
Wer so arbeitet, kennt auch den Begriff der „Merge-H\u00f6lle“. Diese tritt n\u00e4mlich dann auf, wenn die Entwicklungs-Branches f\u00fcr unterschiedliche Features und der trunk im Code zu weit auseinander laufen oder Code in der gleichen Datei mehrfach umgebaut wurde. Dann n\u00e4mlich funktioniert der Merge nicht mehr so einfach:<\/p>\n
![\"\"](\"http:\/\/abramowitsch.de\/blog\/wp-content\/uploads\/2013\/10\/101313_1029_Verwendenvo2.png\")
<\/p>\n
Wenn es sich dabei nur um eine Code-Datei handelt, ist das zwar \u00e4rgerlich, aber noch akzeptabel. Die Merge-H\u00f6lle ergibt sich, wenn sehr viele Dateien in unterschiedlichen Entwicklungszweigen ver\u00e4ndert wurden und vielleicht sogar noch neue Dateien mit gleichem Namen angelegt wurden. Dann funktioniert in der Regel der Merge nicht mehr und man verbringt Stunden und Tage damit, die Konflikte aufzul\u00f6sen und hofft, dass danach noch alles so funktioniert, wie es man gedacht war.<\/p>\n
Weiterhin kann es passieren, dass Probleme, die in einem Branch gefixt wurden, durch den Merge wieder verloren gehen.<\/p>\n
Hier kann das Feature-Toggle-Pattern Abhilfe schaffen:<\/p>\n
Anstelle der Verwendung unterschiedlicher Entwicklungs-Branches findet sie Entwicklung immer auf dem gleichen Branch (trunk) statt. Martin Fowler hat in seinem Artikel „Feature Toggle<\/a>“ (http:\/\/martinfowler.com\/bliki\/FeatureToggle.html<\/a>) detailliert beschrieben, wie das Feature-Toggle Pattern funktioniert.<\/p>\n Damit ist es m\u00f6glich, auch noch „experimentellen“, noch nicht fertigen Code in Produktivsystemen zu releasen. Man muss quasi nur sicherstellen, dass der unfertige Code nie ausgef\u00fchrt wird. Dadurch arbeitet jeder immer auf dem aktuellen Entwicklungszweig und kann \u00c4nderungen an der Codebasis registrieren und darauf reagieren.<\/p>\n Doch wie setzt man das Feature Toggle Pattern in der Praxis um?<\/p>\n Wichtig ist, dass die Stelle, an der das Feature aktiviert bzw. deaktiviert wird, sp\u00e4ter einfach zu finden und zu entfernen ist, wenn das Feature „produktiv“ geschaltet wird. Wenn ein Schalter nicht entfernt wird, b\u00fcrdet man sich unn\u00f6tigerweise „technische Schulden“ auf. Am einfachsten geht das beispielsweise mit einer (abstrakten) Klasse, die eine Property „IsEnabled“ zur Verf\u00fcgung stellt und von der alle Feature Schalter erben:<\/p>\n internal { } <\/p>\n Von dieser Klasse FeatureSwitch leitet man nun einfach einen Schalter f\u00fcr das eigene Feature („MyFeature“) ab:<\/p>\n internal { <\/p>\n { } }<\/span> Hier wird das Feature by-default eingeschaltet (_inEnabled = true). Genauso einfach kann das Feature auch wieder deaktiviert werden.<\/p>\n Im Code verwendet man den Schalter dann so:<\/p>\n MyFeatureSwitch myFeature = new <\/p>\n if (myFeature.IsEnabled) { } else { <\/p>\n } <\/p>\n Man instanziiert einfach an einer beliebigen Stelle, an der das Feature verwendet wird, den FeatureSwitch. Dort pr\u00fcft man dann \u00fcber die Eigenschaft „IsEnabled“, ob das Feature „scharf geschaltet“ ist und implementiert den Code so, als wenn das Feature produktiv verwendet wird.<\/p>\n
\nabstract
\nclass
\nFeatureSwitch
\n<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/p>\n
\n<\/span><\/p>\n
\npublic
\nabstract
\nbool
\nIsEnabled { get; set; }
\n<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/p>\n
\n<\/span><\/p>\n
\nclass
\nMyFeatureSwitch : FeatureSwitch
\n<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/p>\n
\n<\/span><\/p>\n
\nprivate
\nbool
\n_isEnabled = true;
\n<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/p>\n
\npublic
\noverride
\nbool
\nIsEnabled
\n<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/p>\n
\n<\/span><\/p>\n
\nget { return
\n_isEnabled; }
\n<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/p>\n
\nset { _isEnabled = value; }
\n<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/p>\n
\n<\/span><\/p>\n
\n<\/span><\/p>\n
\nMyFeatureSwitch();
\n<\/span><\/span><\/span><\/span><\/span><\/span><\/p>\n
\n<\/span><\/span><\/span><\/span><\/p>\n
\n<\/span><\/p>\n
\n\/\/ implement feature code here …
\n<\/span><\/span><\/span><\/p>\n
\n<\/span><\/p>\n
\n<\/span><\/span><\/p>\n
\n<\/span><\/p>\n
\n<\/span><\/p>\n