Omstrukturera projekt med hjälp av GitHub Copilot för modernisering

Den här artikeln beskriver hur du använder funktionen för omarkitektur i GitHub Copilot modernisering för att skriva om projekt från äldre ramverk till moderna arkitekturer, till exempel från Struts till Spring MVC.

Översikt

Med funktionen för omarkitektur kan du omvandla ett helt projekt från ett äldre ramverk till en modern arkitektur med hjälp av ett AI-baserat arbetsflöde med flera agenter. I stället för manuell fil-för-fil-migrering beskriver du den önskade omvandlingen på naturligt språk och moderniseringsagenterna hanterar analys, planering och kodgenerering.

Vanliga scenarier för omarkitektur är:

• Struts till Spring MVC
• Från Struts till Spring Boot
• JSP till Thymeleaf
• EJB till Spring Boot
• WebSphere-program till Spring Boot
• Äldre servlet-baserade program till moderna Spring-baserade arkitekturer
• Windows Forms (WinForms) skrivbordsprogram till Angular-webbprogram
• ASP.NET MVC klientdelsprogram till Angular-webbprogram

Förutsättningar

• Visual Studio Code med tillägget GitHub Copilot modernisering installerat.
• En GitHub Copilot-abonnemang. Mer information finns i Copilot planer.
• (Valfritt) Python 3.7 eller senare för att skapa ett kunskapsdiagram, vilket ger agenten en tydligare förståelse för projektstrukturen under omskrivningsprocessen. Om Python inte är tillgängligt utlämnas steget med kunskapsgrafen.
• (Valfritt) Node.js 18 eller senare för att köra Playwright-tester som en del av körningsverifieringen. Om Node.js inte är tillgängligt utlämnas Playwright-teststeget.
• (Valfritt) Docker Desktop för körningsverifiering. Om Docker inte är tillgängligt hoppas körningsvalideringssteget över.

Använda agenten för omarkitektur

Använd modernisera agenten i GitHub-Copilot Chat-panelen.

Använd följande steg för att skapa ett projekt igen:

1. Öppna projektet i Visual Studio Code.

2. Öppna panelen GitHub Copilot Chat.

3. Välj agenten modernize i agentlistan.

4. Beskriv den transformering som du vill utföra. Som exempel:

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

Agenten samordnar ett team med flera agenter som utför följande steg:

1. Analys – undersöker den befintliga kodbasen och identifierar ramverksmönster, beroenden och modulgränser.
2. Planering – Genererar en strukturerad implementeringsplan med ordnade uppgifter och kravspårning.
3. Körning – Tillämpar kodtransformeringar som följer planen, med valideringskontroller i varje steg.

Ge mer kontext

Du kan förbättra omvandlingsresultatet genom att ange ytterligare kontext i din fråga:

• Ange målramverksversioner, till exempel "Använd Spring Boot 3.2 och Java 21".
• Referensdokumentationslänkar eller migreringsguider.
• Beskriv organisationsspecifika mönster eller konventioner.
• Ange vilka moduler eller paket som ska prioriteras.

Som exempel:

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.

Felsökning av vanliga problem

Under omarkitektursprocessen genererar agenten artefakter i katalogen för .github/modernize/ projektet. Använd dessa artefakter för att diagnostisera problem när de uppstår.

Granska genererade artefakter

Katalogen .github/modernize/rearchitecture innehåller följande nyckelresurser:

• board.md – Aktivitetstavlan som spårar varje fas och dess status. Kontrollera den här filen för att se vilka uppgifter som har klarat, misslyckats eller behöver iterationer.
• artifacts/ – Detaljerade rapporter från varje aktivitet. Filer följer en namngivningskonvention, till exempel t21-tester-report.md för den första testrapporten eller t21.2-tester-report.md för ett nytt försök.
• learn.md – En kumulativ kunskapsbas för upptäckter, buggresultat och tekniker som loggas av varje roll under aktivitetskörningen. I den här filen finns insikter om problem som agenten påträffade och hur den löste dem.
• team/ – Rollspecifika stadgar som definierar varje agent ansvar.

När en kvalitetsgräns inte uppfylls, skapar agenten iterationsartefakter (t21.1, t21.2) som dokumenterar korrigeringsförsöken. Leta efter de här numrerade iterationerna för att förstå hur ett problem identifierades och löstes.

Granska analysen och planen

Innan agenten börjar skriva kod skapar den analyser och planeringsartefakter som du bör granska. Dessa artefakter ger dig insyn i vad agenten förstod om ditt projekt och vad det avser att bygga.

Bland analysartefakterna finns:

• Arkitektursammanfattning: En översikt över den befintliga teknikstacken, projektstrukturen, datamodellen och integreringspunkterna. Kontrollera den här sammanfattningen för att kontrollera att agenten har identifierat projektets nyckelkomponenter korrekt. Leta efter filer som artifacts/t2-architect-architecture-summary.md, artifacts/t2-architect-tech-stack.mdoch artifacts/t2-architect-data-model.md.
• Funktionsinventering: En katalog med alla funktioner i det ursprungliga programmet, var och en tilldelad ett krav-ID (till exempel REQ-001). Kontrollera att listan är fullständig och korrekt. Leta efter artifacts/t3-pm-spec.md.
• Målarkitekturdesign: De föreslagna API-kontrakten, modulstrukturen och teknikvalen för det nya programmet. Leta efter filer som artifacts/t5-architect-api-contracts.md och artifacts/t5-architect-integration.md.

Planeringsartefakterna omfattar:

• Implementeringsplan: En ordnad lista över uppgifter med beroenden, grupperade i faser. Varje uppgift mappas tillbaka till ett eller flera krav från funktionsinventeringen. Leta efter artifacts/t7-teamlead-plan.md.
• Teststrategi: Den planerade metoden för enhetstester, integreringstester och slutpunkt till slutpunkt-tester. Leta efter artifacts/t7-teamlead-testing-strategy.md.

Agenten pausar efter att ha genererat dessa artefakter och väntar på din bekräftelse. Använd den här möjligheten för att:

• Kontrollera att inga funktioner saknas i inventeringen.
• Kontrollera att målarkitekturen matchar dina förväntningar.
• Justera aktivitetsprioriteringar eller lägg till begränsningar innan implementeringen påbörjas.

Noggrann granskning i det här skedet hjälper till att undvika kostsamma omarbetningar under implementerings- och valideringsfaserna.

Bygg- och startfel

Om det transformerade programmet inte kompilerar eller startar använder du följande metod:

1. Kontrollera testrapportens artefakt (till exempel t21-tester-report.md) för buildresultat och stacktraces.
2. Sök efter undantagstypen eller felmeddelandet i artefakten för att identifiera grundorsaken.
3. Om agenten har skapat korrigerings-iterationer (till exempel t21.1, t21.3) granskar du artefakterna för att se vilka ändringar som har gjorts.

Vanliga rotorsaker är namngivningskollisioner mellan äldre och nyligen genererade klasser, felaktiga konfigurationer av Spring-profiler och saknade eller motstridiga beroenden i pom.xml. Om till exempel äldre och moderna kontrollar har samma klassnamn, genererar Spring en ConflictingBeanDefinitionException vid start.

Körningsfel

Om applikationen startar men API-anrop returnerar fel, till exempel 500 eller 400 svar, använder du följande tillvägagångssätt:

1. Kontrollera artefakten från testrapporten för vilka slutpunkter som misslyckades och de tillhörande felmeddelandena.
2. Granska artefaktet för säkerhetsfynd (till exempel t20-security-findings.md) för konfigurationsproblem.
3. Granska de genererade entitetsklasserna och styrenhetskoden efter skillnader mellan databasschemat och ORM-mappningarna.

Vanliga rotorsaker är databasreserverade nyckelordskonflikter i @Column anteckningar, matchningsfel mellan DTO-fälttyper och entitetsfälttyper och saknade valideringsanteckningar för begärandeobjekt.

Fel och iterationer i kvalitetsgrindar

Agenten tillämpar flera kvalitetskontroller under processen för omstrukturering. När en gate misslyckas skapar agenten automatiskt korrigeringsuppgifter och försöker igen med validering. Vanliga grindfel är:

• Arkitekturgranskning: Agenten kontrollerar att implementeringen matchar de utformade API-kontrakten, DTO-strukturerna och slutpunktsmappningarna. Fel omfattar vanligtvis saknade slutpunkter, omdöpta fält eller saknade valideringsanteckningar. Granska artefakten för arkitekturrapporten (till exempel t19-architect-review.md) för specifika fynd.
• Efterlevnadsgranskning: Agenten verifierar att implementeringen uppfyller alla principer som definierats i den ursprungliga konstitutionen. Ett vanligt misstag är att sakna end-to-end-tester på webbläsarnivå när kraven kräver dem. Granska artefakten för teamledarens granskning (till exempel t22-teamlead-review.md) för att identifiera vilka principer som inte uppfylldes.
• Funktionsparitetsgodkännande: Agenten verifierar att alla katalogiserade krav implementeras. En partiell signering innebär att specifika funktioner är ofullständiga, till exempel saknas validering mellan fält, till exempel att säkerställa fromDate är före toDate. Granska pm-signeringsartefakten (till exempel t23-pm-signoff.md) för uppdelningen krav för krav.

Om agenten når iterationsgränsen utan att lösa alla problem kan du läsa de senaste artefaktfilerna för att förstå återstående luckor och tillämpa manuella korrigeringar.

Krav för körningsverifiering

Agenten utför valfria verifieringssteg som körs vid behov och är beroende av externa verktyg. Om ett verktyg inte är tillgängligt hoppar över motsvarande steg.

• Python inte installerat: Kunskapsdiagramsteget har förbigåtts. Agenten kan fortfarande utföra omarkitekturen, men kan ha mindre kontext om projektstrukturen. Installera Python 3.7 eller senare och se till att python3 finns i din PATH.
• Node.js inte installerat: Tester på webbläsarnivå från slutpunkt till slutpunkt hoppas över. Agenten kör fortfarande integreringstester via Maven. Installera Node.js 18 eller senare för att aktivera webbläsartestning.
• Docker är inte tillgängligt: Driftsvalidering (starta programmet i en container och verifiera att det hanterar begäranden) hoppar över. Agenten förlitar sig i stället på enhets- och integreringstester. Installera och starta Docker Desktop för att aktivera det här steget.

Begränsningar

Tänk på följande begränsningar:

• Komplexa projekt med djupt kopplade äldre ramverk kan kräva flera iterationer.
• Du bör granska genererad kod noggrant innan du genomför ändringar.

Lämna feedback

Om du har feedback om funktionen för omstrukturering, öppna ett ärende på github-copilot-appmod-kodförrådet eller använd GitHub Copilot-moderniseringsformuläret för feedback.

Se även

Översikt över GitHub Copilot-modernisering för Java