Ich werde versuchen, mich kurz zu fassen, um dies nicht zu einem Blogbeitrag zu machen. Wenn es spezifische Fragen gibt, lassen Sie es mich wissen und ich werde mein Bestes tun, um sie zu beantworten.
Im Grunde interessiert mich, welche Methoden sich die Leute ausgedacht haben und welche Vorteile und Defizite sie erlebt haben, um den Übergang eines Projekts von einem Framework (oder einer Programmiersprache oder einem Technologie-Stack) zu einem anderen zu verwalten.
Angenommen, Sie hatten eine einfache Webanwendung, die in einem einst beliebten Back-End-Framework geschrieben war, das auf einem einzelnen Apache/Nginx/was auch immer-Server lief und serverseitig gerenderte Seiten lieferte. Jedes Mal, wenn ein Benutzer auf einen Link klickt, um eine Aktion auszuführen, wird die Anfrage an den Server gesendet, der eine Server bearbeitet die Anfrage, stellt eine Verbindung zu der einen Datenbank her, nimmt die Änderungen vor und liefert dann eine neue Seite mit den sichtbaren Ergebnissen seiner Aktion.
Angenommen, Ihre App hat sich in 10 Jahren zu einem weit verbreiteten Giganten entwickelt und Sie haben Probleme mit der Skalierung, Sie haben Leistungsprobleme und Sie können Funktionen nicht sehr schnell erstellen, da der gesamte Code teilweise eng miteinander verbunden ist Große Namen haben begonnen, je nachdem, ob Ihr Dienst "Always Available" ™ ist, oder aus einem anderen Grund müssen Sie jetzt die Engine ändern, die Ihrer App zugrunde liegt.
Nach wochenlanger Recherche haben Sie vielleicht eine kleine Entscheidung getroffen, wie „Lasst uns React verwenden und einen Großteil der Verarbeitungs- und Anzeigelogik auf die CPU des Clients auslagern“, oder Sie haben möglicherweise mehrere Entscheidungen getroffen, bei denen Sie Ihre App in mehrere Mikrodienste aufgeteilt haben und Neuerfindung der Datenbank mit einem Map-Reduce-Algorithmus und einem Spritzer maschinellen Lernens. Was auch immer die endgültige Entscheidung war, Sie müssen die Funktionsgleichheit mit Ihrer alten App beibehalten und sie auf das neue Framework übertragen.
Bei dieser Frage geht es nicht um die technischen Details dieser Entscheidung (z. B. „Wie machst du das“) – es geht um die verwaltungstechnischen Details dieser Entscheidung. Wie bewältigt man eine solche Veränderung?
Behandeln Sie es so, als würden Sie eine neue App von Grund auf neu erstellen und jedes Feature in der alten App ist nur eine User Story in der neuen?
Oder behandeln Sie es als neues Feature für die bestehende App?
Sollten Sie vom alten Code abzweigen und die Überarbeitung an einem neuen Zweig des alten Repositorys beginnen?
Oder sollten Sie ein neues Repository für das neue Framework starten, da Zusammenführungskonflikte nicht nur erwartet werden, sondern fast ein Hindernis darstellen, da Ihre zugrunde liegenden Modelle und Annahmen völlig anders sein könnten?
Was wird in der Übergangszeit aus der alten App? Sollten Sie es einfrieren, um die Parität zu erleichtern? Oder soll man sich parallel weiterentwickeln?
Ich habe viele Methoden zum Verwalten von Projekten gesehen und aus allem, was ich gesehen habe, meine Lieblingstools ausgewählt. Aber ich habe noch nie jemanden gesehen, der es geschafft hat, Frameworks gut zu ändern. Selbst etwas vermeintlich Einfaches wie der Wechsel von ReactJS zu Vue (sie dienen demselben Zweck, sie sind beide in JavaScript geschrieben und viele der zugrunde liegenden Annahmen und mentalen Modelle sind identisch) kann zu monatelanger Entwicklung und verschwendeter Zeit führen, bevor die Änderung erfolgt verschrottet, weil es sich einfach nicht gelohnt hat.
Ich hatte buchstäblich keine Ahnung, welche Tags ich wählen sollte. Bitte helfen Sie.
Ich habe das ein paar Mal gemacht, obwohl es nicht immer eine Webapp war und nicht aus Skalierungsgründen. Folgendes haben wir getan:
Ein paar technische Punkte:
Wir hatten bereits eine große Anzahl von Regressionstests und die Bedenken drehten sich hauptsächlich um numerische Ergebnisse. Wir haben alle unsere Patches zum Reproduzieren von Fehlern in dasselbe Modul mit einem offensichtlichen Namen eingefügt und den korrekten Code in den Kommentaren beibehalten, sodass es einfach ist, die Patches zu entfernen, wenn sie fertig sind.
Es besteht eine Spannung zwischen den einfachen Dingen zuerst zu tun, damit Sie das Konzept beweisen und so schnell wie möglich eine Untergruppe zum Laufen bringen und überprüfen können, und die kompliziertesten Dinge zuerst zu tun, damit Sie am Ende nicht neu entwerfen müssen auf der Hälfte des Weges. Die übliche agile Annahme, das Einfachste zu tun, was funktioniert, und nach Bedarf umzugestalten, passt meiner Meinung nach etwas nicht zu dieser Situation, da Sie in diesem Fall wissen, dass Sie es brauchen werden. Ich könnte vorschlagen, dass ein Teil des Teams in die Analyse der kompliziertesten Bits investiert, während die anfängliche Infrastruktur, Technologieauswahl/Lernkurve usw. weitergeht.
Ich erwähne das, weil eines meiner Migrationsprojekte aus diesem Grund deutlich über den geplanten Zeitplan hinauslief: Wir haben zuerst die einfachen Dinge erledigt und mussten dann unter Zeitdruck die Komplexität einschieben.
Hoffe das hilft! Mich würden auch andere Antworten interessieren.
Ich glaube nicht, dass es darauf eine "richtige" Antwort gibt. Vickis Antwort ist vollkommen gültig. Ich werde eine andere Antwort geben, die ich für richtig halte.
Beginnen Sie damit, eine Liste der größten Probleme zu erstellen, die Ihre Anwendung derzeit hat. Vielleicht ist das Datenbankredundanz, Ladezeit, architektonische Fragilität, Testabdeckung, was auch immer. Sortieren Sie diese Liste nun in einen Verbesserungsrückstand. Beginnen Sie nun oben und arbeiten Sie sich nach unten vor.
Einfach richtig? Nun, es gibt ein paar Dinge zu beachten:
1) ist der Code Ihrer Anwendung lose gekoppelt oder besser noch entkoppelt? Wie viele Teile kannst du heraustrennen? Wenn Sie viele eng gekoppelte Komponenten haben, stecken Sie wahrscheinlich in einem vollständigen Ersetzungsansatz fest, wie Vicki vorschlägt, oder Sie müssen einige Anstrengungen unternehmen, um die Architektur und Wartbarkeit Ihrer Anwendung zu verbessern, bevor Sie etwas anderes tun können.
2) Kleine Teilkorrekturen oder große Korrekturen? Nehmen wir Ihr React-Beispiel. Nehmen wir für einen Moment an, dass Ihre vorhandene Benutzeroberfläche mit Webdiensten für die Geschäftslogik kommuniziert. Sie könnten einfach die gesamte UI-Seite ersetzen und React mit den Webdiensten kommunizieren lassen. Das kann auch eine Anpassung der Webservices für REST bedeuten, wenn Sie zuvor SOAP oder das Microsoft-Webservice-Protokoll verwendet haben. Dies ist eine große Lösung für das Problem der Ressourcen. Andererseits kann eine kleine Lösung so einfach sein wie das Hinzufügen von Hardware oder eine Lastausgleichslösung. Wenn Sie dies tun, wird das Problem möglicherweise nicht dauerhaft behoben, aber es kann das Problem im Rückstand viel weiter nach unten treiben. Für die Kosten von einem oder drei Servern haben Sie sich gerade ein Jahr in Ihrer Anwendung gekauft und können sich auf andere Probleme konzentrieren, die schwieriger zu lösen sind als der Kauf einiger zusätzlicher CPUs.
3) Konzentrieren Sie sich auf die Lösung von Problemen, nicht auf die Implementierung von Designs. Für jeden dieser Punkte besteht das Ziel darin, den Betrag der Ladegeschwindigkeit X zu verbessern oder Fehler auf den Schwellenwert Y zu reduzieren. Wenn Sie nur Stück für Stück eine vordefinierte Lösung implementieren, ist es möglicherweise besser, einen vollständigen Ersatzansatz zu wählen, da Sie dies im Grunde sowieso tun. Dieser Ansatz zahlt sich nur aus, wenn Sie die Vorteile der Lösung jedes Problems nutzen, während Sie fortfahren.
Wie gesagt, es gibt nicht unbedingt eine "richtige" Antwort, bei welcher dieser Herangehensweisen an Bilder oder wie Sie diese Herangehensweise durchlaufen würden. Bei diesem Ansatz treffen Sie iterativ die jeweils besten Entscheidungen und erhalten Vorteile, während Sie fortfahren. Beim anderen Ansatz können Sie ohne Einschränkungen von Null anfangen, aber Sie finden erst am Ende heraus, ob Ihr neuer Ansatz das Problem löst. Sie müssen Ihre Situation betrachten und entscheiden, was richtig ist.