Projecten opnieuw ontwerpen met behulp van GitHub Copilot modernisering

In dit artikel wordt beschreven hoe u de functie voor herarchitectuur in GitHub Copilot modernisering gebruikt om projecten te herschrijven van verouderde frameworks naar moderne architecturen, zoals van Struts naar Spring MVC.

Overzicht

Met de functie voor opnieuw architectuur kunt u een volledig project transformeren van een verouderd framework naar een moderne architectuur met behulp van een werkstroom met meerdere agents die door AI worden aangedreven. In plaats van handmatige bestandsmigratie beschrijft u de gewenste transformatie in natuurlijke taal en verwerken de moderniseringsagenten analyse, planning en het genereren van code.

Veelvoorkomende scenario's voor opnieuw architectuur zijn:

  • Struts naar Spring MVC
  • Struts naar Spring Boot
  • JSP naar Thymeleaf
  • EJB naar Spring Boot
  • WebSphere-toepassingen naar Spring Boot
  • Verouderde op servlet gebaseerde toepassingen naar moderne Spring-architecturen
  • Windows Forms bureaubladtoepassingen (WinForms) voor Angular-webtoepassingen
  • ASP.NET MVC front-endtoepassingen voor Angular-webtoepassingen

Vereiste voorwaarden

  • Visual Studio Code met de GitHub Copilot modernization extensie geïnstalleerd.
  • Een GitHub Copilot-abonnement. Zie Copilot plans voor meer informatie.
  • (Optioneel) Python 3.7 of hoger voor het bouwen van een kennisgrafiek, waardoor de agent een duidelijker inzicht krijgt in uw projectstructuur tijdens het herschrijven. Als Python niet beschikbaar is, wordt de kennisgrafiekstap overgeslagen.
  • (Optioneel) Node.js 18 of hoger voor het uitvoeren van Playwright-tests als onderdeel van runtimevalidatie. Als Node.js niet beschikbaar is, wordt de teststap Playwright overgeslagen.
  • (Optioneel) Docker Desktop voor runtimevalidatie. Als Docker niet beschikbaar is, wordt de runtimevalidatiestap overgeslagen.

De agent voor herstructurering gebruiken

Gebruik de moderniseringsagent in het GitHub Copilot Chat-deelvenster.

Gebruik de volgende stappen om een project opnieuw te ontwerpen:

  1. Open uw project in Visual Studio Code.

  2. Open het deelvenster GitHub Copilot Chat.

  3. Selecteer de modernize-agent in de agentlijst.

  4. Beschrijf de transformatie die u wilt uitvoeren. Voorbeeld:

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

De agent coördineert een multiagentteam dat de volgende stappen uitvoert:

  1. Analyse : onderzoekt de bestaande codebasis, het identificeren van frameworkpatronen, afhankelijkheden en modulegrenzen.
  2. Planning : genereert een gestructureerd implementatieplan met geordende taken en traceerbaarheid van vereisten.
  3. Uitvoering : past codetransformaties toe na het plan, met validatiecontroles bij elke stap.

Belangrijk

Nadat de analyse- en planningsfasen zijn voltooid, pauzeert de agent en vraagt om uw bevestiging voordat de code wordt gegenereerd. Bekijk het plan op dit moment zorgvuldig. U kunt wijzigingen in het plan aanvragen, prioriteiten aanpassen of beperkingen toevoegen voordat de agent verdergaat met de implementatie.

Meer context bieden

U kunt de transformatieresultaten verbeteren door extra context in uw prompt op te geven:

  • Geef doelframeworkversies op, bijvoorbeeld 'Spring Boot 3.2 en Java 21 gebruiken'.
  • Referentiedocumentatielinks of migratiehandleidingen.
  • Organisatiespecifieke patronen of conventies beschrijven.
  • Geef aan welke modules of pakketten prioriteit moeten krijgen.

Voorbeeld:

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.

Veelvoorkomende problemen oplossen

Tijdens het herarchitectuurproces genereert de agent artefacten in de .github/modernize/ map van uw project. Gebruik deze artefacten om problemen vast te stellen wanneer ze zich voordoen.

Gegenereerde artefacten beoordelen

De .github/modernize/rearchitecture map bevat de volgende belangrijke resources:

  • board.md - Het taakbord dat elke fase en de status ervan bijhoudt. Controleer dit bestand om te zien welke taken zijn geslaagd, mislukt of vereiste iteraties.
  • artifacts/ - Gedetailleerde rapporten van elke taak. Bestanden volgen een naamconventie, zoals t21-tester-report.md voor het eerste testrapport of t21.2-tester-report.md voor een iteratie voor opnieuw proberen.
  • learn.md - Een cumulatieve knowledge base van ontdekkingen, foutresultaten en technieken die tijdens de uitvoering van de taak door elke rol zijn vastgelegd. Controleer dit bestand op inzichten in problemen die de agent heeft aangetroffen en hoe deze zijn opgelost.
  • team/ - Rolspecifieke charters die de verantwoordelijkheden van elke agent definiëren.

Wanneer een kwaliteitspoort mislukt, maakt de agent iteratieartefacten (bijvoorbeeld t21.1t21.2, ) die de fixpogingen documenteren. Zoek naar deze genummerde iteraties om te begrijpen hoe een probleem is gedetecteerd en opgelost.

De analyse en het plan controleren

Voordat de agent begint met het schrijven van code, produceert deze analyse- en planningsartefacten die u moet controleren. Deze artefacten geven u inzicht in wat de agent heeft begrepen over uw project en wat de agent wil bouwen.

De analyseartefacten zijn onder andere:

  • Overzicht van de architectuur: Een overzicht van de bestaande technische stack, projectstructuur, gegevensmodel en integratiepunten. Controleer deze samenvatting om te controleren of de agent de belangrijkste onderdelen van uw project correct heeft geïdentificeerd. Zoek naar bestanden zoals artifacts/t2-architect-architecture-summary.md, artifacts/t2-architect-tech-stack.mden artifacts/t2-architect-data-model.md.
  • Functie-inventaris: Een catalogus met alle functies in de oorspronkelijke toepassing, waarbij elk een vereiste-id (bijvoorbeeld REQ-001) is toegewezen. Controleer of deze lijst volledig en nauwkeurig is. Zoek naar artifacts/t3-pm-spec.md.
  • Ontwerp van doelarchitectuur: de voorgestelde API-contracten, modulestructuur en technologische keuzes voor de nieuwe toepassing. Zoek naar bestanden zoals artifacts/t5-architect-api-contracts.md en artifacts/t5-architect-integration.md.

De planningartefacten zijn onder andere:

  • Implementatieplan: Een geordende lijst met taken met afhankelijkheden, gegroepeerd in fasen. Elke taak wordt weer toegewezen aan een of meer vereisten uit de functie-inventaris. Zoek naar artifacts/t7-teamlead-plan.md.
  • Teststrategie: De geplande aanpak voor eenheidstests, integratietests en end-to-endtests. Zoek naar artifacts/t7-teamlead-testing-strategy.md.

De agent onderbreekt na het genereren van deze artefacten en wacht op uw bevestiging. Gebruik deze mogelijkheid om het volgende te doen:

  • Controleer of er geen functies ontbreken in de inventaris.
  • Controleer of de doelarchitectuur voldoet aan uw verwachtingen.
  • Pas taakprioriteiten aan of voeg beperkingen toe voordat de implementatie begint.

Zorgvuldige controle in deze fase helpt kostbare herwerkbewerkingen te voorkomen tijdens de implementatie- en validatiefasen.

Build- en opstartfouten

Als de getransformeerde toepassing niet kan worden gecompileerd of gestart, gebruikt u de volgende methode:

  1. Controleer het testerrapportbestand (bijvoorbeeld t21-tester-report.md) voor build-uitvoer en stacktraces.
  2. Zoek het uitzonderingstype of het foutbericht in het artefact om de hoofdoorzaak te identificeren.
  3. Als de agent iteraties heeft gemaakt (bijvoorbeeld t21.1, t21.3), controleert u deze artefacten om te zien welke wijzigingen zijn geprobeerd.

Veelvoorkomende hoofdoorzaken zijn naamgevingsconflicten tussen verouderde en nieuw gegenereerde klassen, onjuiste Spring-profielconfiguraties en ontbrekende of conflicterende afhankelijkheden in pom.xml. Als verouderde en moderne controllers bijvoorbeeld dezelfde klassenaam delen, genereert Spring een ConflictingBeanDefinitionException opstartproces.

Runtime fouten

Als de toepassing wordt gestart maar API-aanroepen fouten retourneren (zoals 500 of 400 antwoorden), gebruikt u de volgende aanpak:

  1. Controleer het testerrapportartefact waarvoor eindpunten zijn mislukt en de bijbehorende foutberichten.
  2. Controleer het artefact voor beveiligingsresultaten (bijvoorbeeld t20-security-findings.md) op configuratieproblemen.
  3. Controleer de gegenereerde entiteitsklassen en controllercode op niet-overeenkomende relaties tussen het databaseschema en de ORM-toewijzingen.

Veelvoorkomende hoofdoorzaken zijn conflicten met gereserveerde trefwoorden in databases in @Column aantekeningen, niet-overeenkomende waarden tussen DTO-veldtypen en entiteitsveldtypen en ontbrekende validatieaantekeningen voor aanvraagobjecten.

Kwaliteitspoortfouten en iteraties

De agent dwingt verschillende kwaliteitspoorten af tijdens het herarchitectuurproces. Wanneer een poort mislukt, maakt de agent automatisch fixtaken en probeert de validatie opnieuw uit te voeren. Veelvoorkomende poortfouten zijn:

  • Architectuurbeoordeling: De agent controleert of de implementatie overeenkomt met de ontworpen API-contracten, DTO-structuren en eindpunttoewijzingen. Fouten omvatten meestal ontbrekende eindpunten, hernoemde velden of ontbrekende validatieaantekeningen. Bekijk het artefact van het architectrapport (bijvoorbeeld t19-architect-review.md) voor specifieke bevindingen.
  • Nalevingsbeoordeling: De agent controleert of de implementatie voldoet aan alle principes die in de eerste grondwet zijn gedefinieerd. Een veelvoorkomende fout is dat end-to-end-tests op browserniveau ontbreken wanneer de grondwet deze vereist. Controleer het beoordelingsartefact van de teamleider (bijvoorbeeld t22-teamlead-review.md) om te bepalen welke principes niet voldaan zijn.
  • Controle op functiepariteit: De agent verifieert of alle vereisten zijn geïmplementeerd. Een gedeeltelijke aftekening betekent dat specifieke functies onvolledig zijn, bijvoorbeeld ontbrekende kruisvalidering zoals ervoor zorgen dat fromDate vóór toDate komt. Controleer het pm-afmeldingsartefact (bijvoorbeeld t23-pm-signoff.md) voor de uitsplitsing van vereisten per vereiste.

Als de agent de iteratielimiet bereikt zonder alle problemen op te lossen, controleert u de meest recente artefactbestanden om de resterende hiaten te begrijpen en handmatige oplossingen toe te passen.

Vereisten voor runtimevalidatie

De agent voert optionele runtimevalidatiestappen uit die afhankelijk zijn van externe hulpprogramma's. Als er geen hulpprogramma beschikbaar is, wordt de bijbehorende stap overgeslagen:

  • Python niet geïnstalleerd: De kennisgrafiekstap wordt overgeslagen. De agent kan nog steeds de herarchitectuur uitvoeren, maar heeft mogelijk minder context over uw projectstructuur. Installeer Python 3.7 of hoger en zorg ervoor dat python3 beschikbaar is in uw PATH.
  • Node.js niet geïnstalleerd: end-to-end tests op browserniveau van Playwright worden overgeslagen. De agent voert nog steeds integratietests uit via Maven. Installeer Node.js 18 of hoger om browsertests in te schakelen.
  • Docker is niet beschikbaar: runtimevalidatie (starten van de toepassing in een container en controleren of deze aanvragen verwerkt) wordt overgeslagen. De agent is afhankelijk van unit- en integratietests. Installeer Docker Desktop en start deze stap om deze stap in te schakelen.

Beperkingen

Houd rekening met de volgende beperkingen:

  • Complexe projecten met diep gekoppelde verouderde frameworks vereisen mogelijk meerdere iteraties.
  • Controleer de gegenereerde code zorgvuldig voordat u wijzigingen doorvoert.

Feedback geven

Als u feedback hebt over de functie voor herarchitectuur, maak dan een issue aan in de github-copilot-appmod repository of gebruik het feedbackformulier voor GitHub Copilot modernisering.

Zie ook

Overzicht van GitHub Copilot-modernisering voor Java