Anwendung Strangler Muster Erfahrungen & Gedanken

Question

Erst vor kurzem kam ich eine Idee, die Anwendung Strangler Muster genannt vorbei. Nach meinem Verständnis ist es eine Lösung für das Problem mit großen Legacy-Systemen. Die Idee ist, eine neue Anwendung um die alte Anwendung zu erstellen. Die Kosten und das Risiko davon sind viel geringer als eine vollständige Neufassung des Systems. Langsam wird die neue Anwendung im Laufe der Zeit immer mehr von der Arbeit machen und die alte Legacy-Anwendung schließlich strangulieren. In der Zwischenzeit arbeiten die Entwickler in einem sauberen, neuen System mit höherer Effizienz und produzieren hoffentlich viel besseren Code.

Wo ich arbeite jetzt wir an den Punkt gekommen waren neue Funktionalität, auch scheinbar triviale Dinge, dauert eine lange Zeit zu entwickeln, mit einem hohen Risiko für etwas zu brechen. Wir sitzen auf ungefähr einer Million Codezeilen, mit Unit-Testabdeckung von vielleicht 1-2%. Das System ist ein SOA-System, das Webdienste verwendet (beides ist nicht wirklich notwendig) und ist mehr prozedural als objektorientiert. Das System ist sowohl web & Win, alle in .net Programmiersprachen geschrieben.

schließlich die Frage: In dieser neuen Idee/Muster unter Berücksichtigung, möchte ich wissen, ob jemand Erfahrung mit der Verwendung dieses Muster hatte sie teilen möchten. Zum Beispiel, was wäre eine gute Möglichkeit, es zu implementieren (zum Beispiel mit Ereignissen aus der alten Anwendung)? Wenn jemand darüber nachdenkt, warum es eine gute oder eine schlechte Idee wäre, würde das auch geschätzt werden.

Referenzen:

• Martin Fowler blog post
• Hanselminutes with Michael Feathers

Answer 1

Das größte Problem ist, zu überwinden Mangel an Willen, tatsächlich die Erdrosselung zu beenden (in der Regel politischer Wille von nicht-technischen Akteuren, als Mangel an Budget manifestierte). Wenn Sie das alte System nicht vollständig ausschalten, werden Sie in einer noch schlimmeren Situation landen, da Ihr System nun zwei Möglichkeiten hat, alles mit einer unangenehmen Schnittstelle zwischen den beiden zu tun. Später wird sich wahrscheinlich eine weitere Welle von Entwicklern dazu entschließen, das, was da ist, zu strangulieren, eine weitere Strangler-Anwendung zu schreiben, und wieder könnte ein Mangel an Willen das System in einem noch schlechteren Zustand mit drei Wegen verlassen.

Wenn das Projekt groß ist, aus mehreren Regionen laufen, dann müssen Sie globalen Konsens darüber, wie der Endzustand aussehen sollte und wie jeder zusammenarbeiten wird, um dorthin zu gelangen. Während die alte App erdrosselt wird, ist es wichtig, dass Remote-Teams jeden Tag kommunizieren, wenn möglich mit der Arbeit kooperieren, indem sie Remote-Pair-Programmierung durchführen und Missverständnisse oder Meinungsverschiedenheiten sofort beheben.Sonst besteht die Gefahr, dass jedes regionale Team beschließt, seine eigene Würger-Anwendung zu schreiben, und sie werden sich irgendwo in der Mitte treffen und kämpfen, was das System noch schlimmer macht.

Was auch immer Sie tun, tun Sie das Refactoring/Strangulieren nicht in einem anderen Zweig als dem Hauptstrom der Entwicklung. Die Verschmelzungsschwierigkeiten werden unüberwindbar werden.

Ich habe kritische Systeme gesehen, die beide diese Schicksale erlitten haben, und endete mit ungefähr vier oder fünf "strategischen architektonischen Richtungen" und "zukünftigen Staatsarchitekturen". Ein großes Multi-Site-Projekt endete mit acht verschiedenen neuen Persistenzmechanismen in seiner neuen Architektur. Ein anderes endete mit zwei verschiedenen Datenbankschemas, eines für die alte Art, Dinge zu tun, und ein anderes für den neuen Weg. Kein Schema wurde jemals aus dem System entfernt und es gab auch mehrere Klassenhierarchien, die einem oder sogar beiden Schemas zugeordnet wurden. Wenn Sie neue Technologien für das Team oder für das Support-/Wartungspersonal einführen (z. B. Hinzufügen von zuverlässigem asynchronen Messaging zu einer derzeit synchronen dreistufigen Client/Server-Architektur), müssen Sie sicherstellen, dass Es gibt erfahrene technische Projektleiter, die wissen, wie man Systeme mit dieser Technologie baut und diese Systeme unterstützt. Und diese Tech-Leads müssen noch eine Weile bei dem Projekt bleiben, nachdem die alte App vollständig erdrosselt wurde. Andernfalls wird sich die Architektur verschlechtern, da unerfahrene Entwickler sie auf bekannte Weise modifizieren, aber nicht so, wie es der neuen Architektur entspricht.

Answer 2

Das große Risiko dieses Muster, dass Sie bodging den alten Code beide am Ende ist und der neue Code, um das Verhalten, das Sie bekommen Notwendigkeit, vor allem, wenn der alte Code nie entworfen wurde, um erdrosselt zu werden (dh nicht saubere konsistente Schnittstellen darstellt).

Meine Erfahrung damit ist, dass das Debuggen mit der Zeit schwieriger wird, da es unklar ist, ob problematische Funktionalität in dem neuen Code oder dem alten Code (oder einem gemeinsamen Problem zwischen den beiden) aufgetreten ist.

Ich weiß, Martin Fowler spricht über das Schreiben von Code, der erdrosselt werden soll, aber meiner Meinung nach ist das einfach eine andere Art zu sagen, dass modulares Design gut ist, mmmkay; es ist nicht umstritten und ziemlich offensichtlich.

Answer 3

Meiner Erfahrung nach besteht der Treiber darin, zusätzliche Funktionalität hinzuzufügen, anstatt die ursprüngliche Codebasis zu veralten. Sobald die neue Funktionalität hinzugefügt wurde, wird der unmittelbare Geschäftsszenario für die Vervollständigung der Änderung geschwächt und die Dynamik geht verloren. Das muss natürlich nicht passieren und Sie sollten dies zunächst vermeiden.

Grüße

Answer 4

Die alte Schule Name dafür ist "Wrapper". Es hört sich toll an; wer will sich mit der alten anwendung anlegen, wenn man etwas neues und sauberes schreiben kann, um es zu isolieren? Das Problem ist, dass es eine Schicht von Schmiere schafft, und es dauert nicht lange, bis jemand entscheidet, dass die Verpackung selbst unordentlich ist. Was ist die Lösung dafür? Noch ein Wrapper? So wie ich es sehe, enden solche Wrapper und "Strangler" im Grunde damit, die ursprüngliche Anwendung zu panzern und schließlich Ihr Leben härter zu machen. Aber die Menschen wählen oft kurzfristige Lösungen, die auf lange Sicht suboptimal sind. Schließlich wird es niemand bemerken, bis Sie lange weg sind.

Answer 5

Die Grundvoraussetzung hinter dem Strangler ist wirklich großartig: anstatt zu versuchen, einen "Big Bang" -Stil auf einmal Ersatz eines Legacy-Systems zu machen, bauen Sie stattdessen eine Würger-Anwendung durch vertikale Schichten in den Schichten, ersetzt jeweils bestehende Funktion nacheinander, bis das ursprüngliche System außer Betrieb genommen werden kann. Es funktioniert gut, in der Theorie und in der Praxis - wahrscheinlich ist eines der besten Dinge daran, dass es das Technologierisiko stark reduziert und einem Team hilft, sich auf den Ersatz der wichtigsten Funktionen zu konzentrieren. Wenn das neue System nicht funktioniert, können die Leute einfach das alte System benutzen.

Was könnte schief gehen?

• Organisationen können feststellen, dass es schwierig werden kann im Zuge neuer Projekte finanziert langfristig Infrastruktur refresh Projekte zu halten, die neue Features versprechen, Wettbewerbsvorteile, Umsatzpotenzial, oder Marktanteil erhöhen - vor allem für Organisationen Das sind konzentriert sich auf ein Produkt oder eine Dienstleistung. Dies ist eines dieser sofort sichtbaren Probleme, und während es ein einfacher Sündenbock ist, ist es in der Regel nicht die einzige Bedrohung.
• Wenn das System mit dem System verbunden ist, sie zu ersetzen übermäßig ersetzt, diese kann die technischen Schwierigkeiten verursachen dramatisch zu erhöhen - es OK sein könnte sie einen spezifischen Integrationspunkt zu haben, teilen, aber mehr als das Problem ist, . Wenn das Team durch die Technologieherausforderungen abgelenkt wird, die sie für sich selbst erstellt haben, arbeiten sie nicht länger effektiv und die Projekt-Zeitleisten sind spiralförmig aus Kontrolle.
• Technologie-Teams, die horizontal organisiert sind, kann eine besonders harte Zeit mit dem StranglerApplication Muster haben, wie die vertikalen Scheiben benötigt, um die Arbeit zu beenden erfordern die Integration mit mehr Abteilungen oder Teams zu vervollständigen, und jede Gruppe ihre eigenen -Release Zyklen, Ziele und organisatorische Zwänge.
• Wenn es eine ist Ersatz von wichtigen technischen oder Managementpersonal während des Projekts, manchmal die neuen Leute, die das Projekt erben feststellen, dass sie nicht das neue System besser als die, die es ersetzt mögen - sie führende um möglicherweise ein drittes System zu starten.
• Manchmal werden Sie vielleicht gelingen teilweise, und eine neue Version eines System erstellen -aber wenn es Zeit zurück zu gehen kommt und neu schreiben Systeme untergeordnete Bedeutung mit dem neuen System zu starten, sind die Menschen zu sehr damit beschäftigt zu machen coole neue Dinge mit das neue System. Jetzt haben Sie zwei Systeme. Oder, wenn Sie bereits einmal getan haben, haben Sie drei.

Alle diese Problempunkte sind natürlich überschaubar. Es kann hilfreich sein, Teams neu zu ordnen, saubere Trennung zwischen Systemen zu halten, besondere Aufmerksamkeit auf Projekt Richtung zu richten und realistische Ziele rund um das Ersetzen des vorhandenen Systems zu setzen.