Projekte mit GitHub Copilot Modernisierung neu entwerfen

In diesem Artikel wird beschrieben, wie Sie das Feature "Neuarchitektur" in GitHub Copilot Modernisierung verwenden, um Projekte von älteren Frameworks in moderne Architekturen wie z. B. von Struts in Spring MVC umzuschreiben.

Übersicht

Mit dem Feature "Neuarchitektur" können Sie ein gesamtes Projekt von einem Legacyframework in eine moderne Architektur umwandeln, indem Sie einen KI-basierten Multi-Agent-Workflow verwenden. Statt manueller Dateimigration beschreiben Sie die gewünschte Transformation in natürlicher Sprache, und die Modernisierungs-Agents behandeln Analyse, Planung und Codegenerierung.

Zu den gängigen Szenarien für die erneute Architektur gehören:

  • Struts zu Spring MVC
  • Von Struts zu Spring Boot
  • JSP zu Thymeleaf
  • EJB zu Spring Boot
  • WebSphere-Anwendungen zum Spring Boot
  • Legacy-servlet-basierte Anwendungen für moderne Spring-basierte Architekturen
  • Windows Forms (WinForms)-Desktopanwendungen zu Webanwendungen mit Angular
  • ASP.NET MVC Frontend-Anwendungen in Angular-Webanwendungen

Voraussetzungen

  • Visual Studio Code mit der GitHub Copilot Modernisierung Erweiterung installiert.
  • Ein GitHub Copilot-Abonnement. Weitere Informationen finden Sie unter Copilot plans.
  • (Optional) Python 3.7 oder höher zum Erstellen eines Wissensdiagramms, das dem Agenten während des Umschreibungsprozesses ein klareres Verständnis der Projektstruktur vermittelt. Wenn Python nicht verfügbar ist, wird der Wissensdiagrammschritt übersprungen.
  • (Optional) Node.js 18 oder höher zum Ausführen von Playwright-Tests als Teil der Laufzeitüberprüfung. Wenn Node.js nicht verfügbar ist, wird der Playwright-Testschritt übersprungen.
  • (Optional) Docker Desktop für laufzeitüberprüfung. Wenn Docker nicht verfügbar ist, wird der Laufzeitüberprüfungsschritt übersprungen.

Verwenden Sie den Umstrukturierungsagenten

Verwenden Sie den Agenten „modernize“ im Chatbereich von GitHub Copilot.

Führen Sie die folgenden Schritte aus, um ein Projekt neu zu entwerfen:

  1. Öffnen Sie Ihr Projekt in Visual Studio Code.

  2. Öffnen Sie den Bereich GitHub Copilot Chat.

  3. Wählen Sie den modernize-Agenten aus der Agentliste aus.

  4. Beschreiben Sie die Transformation, die Sie ausführen möchten. Beispiel:

    Rewrite the entire project from Struts to Spring MVC using rearchitecture agent

Der Agent koordiniert ein Multi-Agent-Team, das die folgenden Schritte ausführt:

  1. Analyse – Untersucht die vorhandene Codebasis, identifiziert Frameworkmuster, Abhängigkeiten und Modulgrenzen.
  2. Planung – Generiert einen strukturierten Implementierungsplan mit sortierten Aufgaben und Anforderungsablaufverfolgung.
  3. Ausführung : Wendet Codetransformationen nach dem Plan mit Überprüfungsprüfungen an jedem Schritt an.

Von Bedeutung

Nach Abschluss der Analyse- und Planungsphase wird der Agent angehalten und nach Ihrer Bestätigung gefragt, bevor die Codegenerierung beginnt. Überprüfen Sie den Plan an diesem Punkt sorgfältig. Sie können Änderungen am Plan anfordern, Prioritäten anpassen oder Einschränkungen hinzufügen, bevor der Agent mit der Implementierung fortfährt.

Bereitstellen von mehr Kontext

Sie können die Transformationsergebnisse verbessern, indem Sie in Ihrer Eingabeaufforderung zusätzlichen Kontext bereitstellen:

  • Geben Sie Zielframeworkversionen an, z. B. "Spring Boot 3.2 und Java 21 verwenden".
  • Referenzdokumentationslinks oder Migrationshandbücher.
  • Beschreiben sie organisationsspezifische Muster oder Konventionen.
  • Geben Sie an, welche Module oder Pakete priorisiert werden sollen.

Beispiel:

Rewrite the entire project from Struts to Spring MVC using Spring Boot 3.2.
Refer to the Spring MVC migration guide at https://docs.spring.io/spring-framework/reference/web/webmvc.html.
Keep the existing backend business logic unchanged.

Häufige Probleme beheben

Während des erneuten Architekturprozesses generiert der Agent Artefakte im .github/modernize/ Verzeichnis Ihres Projekts. Verwenden Sie diese Artefakte, um Probleme zu diagnostizieren, wenn sie auftreten.

Überprüfen Sie die generierten Artefakte

Das .github/modernize/rearchitecture Verzeichnis enthält die folgenden Schlüsselressourcen:

  • board.md - Das Aufgabenboard, das jede Phase und ihren Status verfolgt. Überprüfen Sie diese Datei, um zu sehen, welche Vorgänge bestanden, fehlgeschlagen oder erforderliche Iterationen ausgeführt wurden.
  • artifacts/ - Detaillierte Berichte aus den einzelnen Vorgängen. Dateien folgen einer Benennungskonvention, z t21-tester-report.md . B. für den anfänglichen Testbericht oder t21.2-tester-report.md für eine Wiederholungsiteration.
  • learn.md – Eine kumulative Wissensbasis von Entdeckungen, Fehlerergebnissen und Techniken, die von jeder Rolle während der Aufgabenausführung protokolliert werden. Überprüfen Sie diese Datei, um Einblicke in Probleme zu erhalten, die der Agent festgestellt hat und wie er sie behoben hat.
  • team/ – Rollenspezifische Chartern, die die Verantwortlichkeiten der einzelnen Agenten definieren.

Wenn eine Qualitätsschranke fehlschlägt, erstellt der Agent Iterationsartefakte (z. B. t21.1, t21.2), die die Korrekturversuche dokumentieren. Suchen Sie nach diesen nummerierten Iterationen, um zu verstehen, wie ein Problem erkannt und behoben wurde.

Überprüfen der Analyse und des Plans

Bevor der Agent mit dem Schreiben von Code beginnt, erzeugt er Analyse- und Planungsartefakte, die Sie überprüfen sollten. Diese Artefakte geben Ihnen Einblicke in das, was der Agent über Ihr Projekt verstanden hat und was er erstellen möchte.

Zu den Analyseartefakten gehören:

  • Architekturzusammenfassung: Eine Übersicht über den vorhandenen Technischen Stapel, die Projektstruktur, das Datenmodell und die Integrationspunkte. Überprüfen Sie diese Zusammenfassung, um zu überprüfen, ob der Agent die wichtigsten Komponenten Ihres Projekts richtig identifiziert hat. Suchen Sie nach Dateien wie artifacts/t2-architect-architecture-summary.md, artifacts/t2-architect-tech-stack.md, und artifacts/t2-architect-data-model.md.
  • Featureinventur: Ein Katalog aller Features in der ursprünglichen Anwendung, jeder zugewiesen eine Anforderungs-ID (z. B REQ-001. ). Stellen Sie sicher, dass diese Liste vollständig und korrekt ist. Suchen Sie nach artifacts/t3-pm-spec.md.
  • Design der Zielarchitektur: Die vorgeschlagenen API-Verträge, Modulstruktur und Technologieoptionen für die neue Anwendung. Suchen Sie nach Dateien wie artifacts/t5-architect-api-contracts.md und artifacts/t5-architect-integration.md.

Zu den Planungsartefakten gehören:

  • Implementierungsplan: Eine sortierte Liste von Aufgaben mit Abhängigkeiten, gruppiert in Phasen. Jede Aufgabe ordnet eine oder mehrere Anforderungen aus dem Feature-Inventar zu. Suchen Sie nach artifacts/t7-teamlead-plan.md.
  • Teststrategie: Der geplante Ansatz für Komponententests, Integrationstests und End-to-End-Tests. Suchen Sie nach artifacts/t7-teamlead-testing-strategy.md.

Der Agent hält nach dem Generieren dieser Artefakte an und wartet auf ihre Bestätigung. Verwenden Sie diese Gelegenheit, um:

  • Stellen Sie sicher, dass im Bestand keine Features fehlen.
  • Überprüfen Sie, ob die Zielarchitektur Ihren Erwartungen entspricht.
  • Passen Sie Vorgangsprioritäten an, oder fügen Sie Einschränkungen hinzu, bevor die Implementierung beginnt.

Eine sorgfältige Überprüfung in dieser Phase trägt dazu bei, während der Implementierungs- und Validierungsphase kostspielige Überarbeitungen zu vermeiden.

Build- und Startfehler

Wenn die transformierte Anwendung nicht kompiliert oder gestartet werden kann, verwenden Sie den folgenden Ansatz:

  1. Überprüfen Sie das Testerbericht-Artefakt (z. B. t21-tester-report.md) auf Buildausgabe- und Stack-Traces.
  2. Suchen Sie im Artefakt nach dem Ausnahmetyp oder der Fehlermeldung, um die Ursache zu identifizieren.
  3. Wenn der Agent Korrektur-Iterationen erstellt hat (z. B. t21.1, t21.3), überprüfen Sie diese Artefakte, um zu sehen, welche Änderungen versucht wurden.

Häufige Ursachen sind Namenskonflikte zwischen Legacy- und neu generierten Klassen, falsche Spring-Profilkonfigurationen und fehlende oder widersprüchliche Abhängigkeiten in pom.xml. Wenn ältere und moderne Controller beispielsweise denselben Klassennamen verwenden, wirft Spring beim Start einen ConflictingBeanDefinitionException.

Laufzeitfehler

Wenn die Anwendung gestartet wird, API-Aufrufe jedoch Fehler zurückgeben (z. B. 500- oder 400-Antworten), verwenden Sie den folgenden Ansatz:

  1. Überprüfen Sie das Testberichtsartefakt, um festzustellen, welche Endpunkte fehlgeschlagen sind, und sehen Sie sich die zugehörigen Fehlermeldungen an.
  2. Überprüfen Sie das Artefakt der Sicherheitsergebnisse (z. B. t20-security-findings.md) auf Konfigurationsprobleme.
  3. Überprüfen Sie die generierten Entitätsklassen und den Controllercode auf Nichtübereinstimmungen zwischen dem Datenbankschema und den ORM-Zuordnungen.

Häufige Ursachen sind Konflikte mit reservierten Datenbank-Schlüsselworten in @Column Annotationen, Nichtübereinstimmungen zwischen DTO-Feld-Typen und Entitätsfeld-Typen und fehlende Validierungs-Annotationen für Anforderungsobjekte.

Quality-Gate-Fehler und Iterationen

Der Agent setzt während des Rearchitekturprozesses mehrere Qualitätskontrollpunkte durch. Wenn ein Gate fehlschlägt, erstellt der Agent automatisch Reparaturaufgaben und führt die Validierung erneut durch. Häufige Gate-Fehler sind:

  • Architekturüberprüfung: Der Agent überprüft, ob die Implementierung den entworfenen API-Verträgen, DTO-Strukturen und Endpunktzuordnungen entspricht. Fehler umfassen in der Regel fehlende Endpunkte, umbenannte Felder oder fehlende Überprüfungsanmerkungen. Überprüfen Sie das Berichtsartefakt des Architekten (z. B. t19-architect-review.md) auf bestimmte Ergebnisse.
  • Konformitätsüberprüfung: Der Agent überprüft, ob die Implementierung alle in der ursprünglichen Verfassung definierten Grundsätze erfüllt. Ein häufiger Fehler fehlt bei End-to-End-Tests auf Browserebene, wenn die Verfassung sie erfordert. Überprüfen Sie das Überprüfungsartefakt des Teamleiters (z. B. t22-teamlead-review.md), um zu ermitteln, welche Prinzipien nicht erfüllt wurden.
  • Featureparitätsfreigabe: Der Agent überprüft, ob alle katalogierten Anforderungen implementiert sind. Eine teilweise Freigabe bedeutet, dass bestimmte Features unvollständig sind, beispielsweise fehlt eine feldübergreifende Überprüfung, wie die Sicherstellung, dass fromDate vor toDate kommt. Überprüfen Sie das PM-Abnahme-Artefakt (z. B. t23-pm-signoff.md) für die anforderungsspezifische Aufschlüsselung.

Wenn der Agent sein Iterationslimit erreicht, ohne alle Probleme zu beheben, überprüfen Sie die neuesten Artefaktdateien, um verbleibende Lücken zu verstehen und manuelle Korrekturen anzuwenden.

Voraussetzungen für die Laufzeitvalidierung

Der Agent führt optionale Laufzeitüberprüfungsschritte aus, die von externen Tools abhängig sind. Wenn ein Tool nicht verfügbar ist, wird der entsprechende Schritt übersprungen:

  • Python nicht installiert: Der Wissensdiagrammschritt wird übersprungen. Der Agent kann die erneute Architektur weiterhin ausführen, hat aber möglicherweise weniger Kontext zu Ihrer Projektstruktur. Installieren Sie Python 3.7 oder höher, und stellen Sie sicher, dass python3 in Ihrem PATH verfügbar ist.
  • Node.js nicht installiert: End-to-End-Tests auf Playwright-Browserebene werden übersprungen. Der Agent führt weiterhin Integrationstests über Maven aus. Installieren Sie Node.js 18 oder höher, um Browsertests zu aktivieren.
  • Docker nicht verfügbar: Die Laufzeitüberprüfung (das Starten der Anwendung in einem Container und die Überprüfung, ob sie Anforderungen erfüllt) wird übersprungen. Der Agent verlässt sich stattdessen auf Unit-Tests und Integrationstests. Installieren und starten Sie Docker Desktop, um diesen Schritt zu aktivieren.

Einschränkungen

Beachten Sie die folgenden Einschränkungen:

  • Komplexe Projekte mit tief gekoppelten Legacyframeworks erfordern möglicherweise mehrere Iterationen.
  • Sie sollten den generierten Code sorgfältig überprüfen, bevor Sie Änderungen übernehmen.

Feedback geben

Wenn Sie Feedback zur Funktion "Neuarchitektur" haben, erstellen Sie ein Problem im Github-copilot-appmod-Repository oder verwenden Sie das GitHub Copilot Modernisierungsfeedbackformular.

Siehe auch

Übersicht über die GitHub Copilot-Modernisierung für Java

  • Last updated on