Auf der Suche nach einer besseren Möglichkeit, tiefgreifendes Architektur-Refactoring mit funktionsbasierter Entwicklung zu kombinieren

Problemstellung:

Gegeben:

TFS als Quellcodeverwaltung
Schwere Desktop-Client-Anwendung mit Tonnen von Legacy-Code mit schlechtem oder fast fehlendem Architekturdesign.
Kunden, die ständig neue Funktionen mit Klangqualität, schneller
Lieferung und ständiger Beschwerde über eine benutzerunfreundliche Benutzeroberfläche benötigen .

Problem:

Die Anwendung erfordert zweifellos ein tiefgreifendes Refactoring. Dieser Prozess macht die Anwendung unweigerlich instabil und es ist eine spezielle Stabilisierungsphase erforderlich.

Wir haben versucht:

Refactoring im Master mit periodischen Zusammenführungen vom Master (MB) zum Feature Branch (FB). (mein Fehler) Ergebnis: Viele instabile Zweige.

Was uns geraten wird:

Link zum Artikel (pdf)
Erstellen Sie einen zusätzlichen Zweig für das Refactoring (RB), der regelmäßig durch Zusammenführen von MB zu RB mit MB synchronisiert wird. Nachdem sich RB stabilisiert hat, ersetzen wir Master durch RB und erstellen einen neuen Zweig für das weitere Refactoring. Das ist der Plan. Aber hier erwarte ich die Hölle, MB mit RB zusammenzuführen, nachdem ich einen FB mit MB zusammengeführt habe.

Der Hauptvorteil: Meistens stabiler Meister.

Gibt es bessere Alternativen zu den Verfahren?

development-process refactoring

— Pavel Voronin
quelle

Mögliche Verbesserungen (anstelle von Alternativen) Ihres vorgeschlagenen Prozesses: Das TFS-Zusammenführungstool ist im Vergleich zu verschiedenen alternativen Diff-Dienstprogrammen ziemlich unhandlich. Wenn Sie dies noch nicht getan haben, ist das manuelle Zusammenführen möglicherweise weniger schmerzhaft, wenn Sie den TFS-Client so konfigurieren, dass er ein besseres Diff-Dienstprogramm als das integrierte Tool verwendet. Möglicherweise ist auch das Dienstprogramm TFS Power Tools von Microsoft hilfreich. Es bietet die Möglichkeit, einen Unterschied zwischen Änderungssätzen oder Zweigen und nicht nur zwischen einzelnen Dateien auszuführen.

— Brian

Ich hatte in der Vergangenheit eine ähnliche Situation. Was ich getan habe:

den aktuellen Stand des Projekts beurteilen; In den meisten Situationen ist die Architektur (oder das Fehlen davon) das Hauptproblem => überdenken Sie es
Normalerweise gibt es funktionierende Merkmale, wobei das Problem die hohe Kopplung zwischen den verschiedenen Teilen des Projekts ist. Ich habe bewertet, welche Funktionen funktionieren, und ich habe sie wiederverwendet, aber in meiner eigenen Architektur
mit dem Kunden sprechen; Ich weiß nicht, was Ihr Manager sagt, aber ich denke, es ist wichtig, mit dem Kunden zu sprechen und offen zu sein. Er muss wissen, dass Sie an der Qualität seines Produkts arbeiten. Ich habe eine Vereinbarung für einen Release-Plan getroffen:
In der Phase des Zusammenführens der beiden Lösungen (Erstellen der Architektur + Wiederverwenden von Funktionen aus dem alten Projekt) wurden die einzigen freigegebenen Dinge (neue Funktionen) für das alte Produkt erstellt. Neuerscheinungen enthielten jedoch nur wichtige Fehlerkorrekturen. Es wurden also nur sehr wenige Veröffentlichungen für das alte Produkt gemacht. Daher konnten die geänderten Dinge leicht in die neue Lösung integriert werden.
Die erste neue Version (Version des neuen Produkts) enthielt nur das, was das alte Produkt enthielt (keine neuen Funktionen). Nach der Stabilisierung (die Stabilisierung dauerte nicht lange) arbeitete ich mit einem einzigen Projekt

Ich denke, man kann sich einer (relativ kurzen) Zeit sporadischer Veröffentlichungen nicht entziehen. Es ist wichtig, dass Sie dies mit Ihrem Kunden vereinbaren können.

— Paul Ianas
quelle