Riprogettare i progetti tramite la modernizzazione con GitHub Copilot

Questo articolo descrive come usare la funzionalità di riarchitettura in GitHub Copilot modernizzazione per riscrivere i progetti dai framework legacy alle architetture moderne, ad esempio da Struts a Spring MVC.

Informazioni generali

La funzionalità di ri-architettura consente di trasformare un intero progetto da un framework legacy a un'architettura moderna usando un flusso di lavoro multi-agente basato su intelligenza artificiale. Invece di eseguire la migrazione manuale per file, descrivere la trasformazione desiderata in linguaggio naturale e gli agenti di modernizzazione gestiscono l'analisi, la pianificazione e la generazione del codice.

Gli scenari comuni di riarchitettura includono:

  • Transizione da Struts a Spring MVC
  • Struts to Spring Boot
  • Da JSP a Thymeleaf
  • Passaggio da EJB a Spring Boot
  • Applicazioni WebSphere in Spring Boot
  • Applicazioni basate su servlet legacy per architetture moderne basate su Spring
  • applicazioni desktop Windows Forms (WinForms) alle applicazioni web Angular
  • Dalle applicazioni frontend ASP.NET MVC alle applicazioni web Angular

Prerequisiti

  • Visual Studio Code con l'estensione modernizzazione di GitHub Copilot installata.
  • Sottoscrizione GitHub Copilot. Per altre informazioni, vedere Copilot plans.
  • (Facoltativo) Python 3.7 o versione successiva per la creazione di un grafico delle conoscenze, che fornisce all'agente una comprensione più chiara della struttura del progetto durante il processo di riscrittura. Se Python non è disponibile, il passaggio del grafico delle informazioni viene ignorato.
  • (Facoltativo) Node.js 18 o versioni successive per l'esecuzione di test Playwright come parte della convalida di runtime. Se Node.js non è disponibile, il passaggio di test playwright viene ignorato.
  • (Facoltativo) Docker Desktop per la convalida del runtime. Se Docker non è disponibile, il passaggio di convalida del runtime viene ignorato.

Usare l'agente di riprogettazione

Usare l'agente di modernizzazione nel pannello Copilot Chat di GitHub.

Per ri-progettare un progetto, seguire questa procedura:

  1. Aprire il progetto in Visual Studio Code.

  2. Aprire il pannello GitHub Copilot Chat.

  3. Selezionare l'agente modernize dall'elenco degli agenti.

  4. Descrivere la trasformazione da eseguire. Per esempio:

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

L'agente coordina un team multi-agente che esegue i passaggi seguenti:

  1. Analisi : esamina la codebase esistente, identificando modelli di framework, dipendenze e limiti del modulo.
  2. Pianificazione: genera un piano di implementazione strutturato con attività ordinate e tracciabilità dei requisiti.
  3. Esecuzione : applica trasformazioni di codice dopo il piano, con controlli di convalida in ogni passaggio.

Importante

Al termine delle fasi di analisi e pianificazione, l'agente sospende e chiede la conferma prima di iniziare la generazione del codice. Esaminare attentamente il piano a questo punto. È possibile richiedere modifiche al piano, modificare le priorità o aggiungere vincoli prima che l'agente proceda con l'implementazione.

Fornire più contesto

È possibile migliorare i risultati della trasformazione fornendo un contesto aggiuntivo nel prompt:

  • Specificare le versioni del framework di destinazione, ad esempio "Usare Spring Boot 3.2 e Java 21".
  • Collegamenti alla documentazione di riferimento o guide alla migrazione.
  • Descrivere modelli o convenzioni specifici dell'organizzazione.
  • Indicare quali moduli o pacchetti assegnare priorità.

Per esempio:

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.

Risolvere i problemi comuni

Durante il processo di riarchitettura, l'agente genera artefatti nella .github/modernize/ directory del tuo progetto. Usare questi artefatti per diagnosticare i problemi quando si verificano.

Esaminare gli artefatti generati

La .github/modernize/rearchitecture directory contiene le risorse chiave seguenti:

  • board.md - Scheda attività che tiene traccia di ogni fase e del relativo stato. Controllare questo file per visualizzare le attività passate, non riuscite o le iterazioni necessarie.
  • artifacts/ - Report dettagliati di ogni attività. I file seguono una convenzione di denominazione, come t21-tester-report.md per il report di test iniziale o t21.2-tester-report.md per un'iterazione di ripetizione.
  • learn.md - Una knowledge base cumulativa di individuazioni, risultati di bug e tecniche registrate da ogni ruolo durante l'esecuzione dell'attività. Controllare questo file per informazioni dettagliate sui problemi riscontrati dall'agente e sul modo in cui li ha risolti.
  • team/ - Carte specifiche del ruolo che definiscono le responsabilità di ogni agente.

Quando un controllo di qualità ha esito negativo, l'agente crea artefatti di iterazione (ad esempio t21.1, t21.2) che documentano i tentativi di correzione. Cercare queste iterazioni numerate per comprendere come è stato rilevato e risolto un problema.

Esaminare l'analisi e il piano

Prima che l'agente inizi a scrivere codice, produce elementi di analisi e pianificazione da esaminare. Questi artefatti offrono visibilità su ciò che l'agente ha compreso riguardo al progetto e su cosa intende costruire.

Gli artefatti di analisi includono:

  • Riepilogo dell'architettura: panoramica dello stack tecnico esistente, della struttura del progetto, del modello di dati e dei punti di integrazione. Controllare questo riepilogo per verificare che l'agente abbia identificato correttamente i componenti chiave del progetto. Cercare file come artifacts/t2-architect-architecture-summary.md, artifacts/t2-architect-tech-stack.md, e artifacts/t2-architect-data-model.md.
  • Inventario delle funzionalità: catalogo di tutte le funzionalità nell'applicazione originale, a ogni ID requisito assegnato (ad esempio, REQ-001). Verificare che l'elenco sia completo e accurato. Cerca artifacts/t3-pm-spec.md.
  • Progettazione dell'architettura di destinazione: i contratti API proposti, la struttura dei moduli e le scelte tecnologico per la nuova applicazione. Cercare file come artifacts/t5-architect-api-contracts.md e artifacts/t5-architect-integration.md.

Gli artefatti di pianificazione includono:

  • Piano di implementazione: elenco ordinato di attività con dipendenze, raggruppate in fasi. Ogni attività ricollega a uno o più requisiti dell'inventario delle funzionalità. Cerca artifacts/t7-teamlead-plan.md.
  • Strategia di test: approccio pianificato per unit test, test di integrazione e test end-to-end. Cerca artifacts/t7-teamlead-testing-strategy.md.

L'agente si sospende dopo la generazione di questi artefatti e attende conferma. Usare questa opportunità per:

  • Verificare che nessuna funzionalità non sia presente nell'inventario.
  • Verificare che l'architettura di destinazione corrisponda alle aspettative.
  • Modificare le priorità delle attività o aggiungere vincoli prima dell'inizio dell'implementazione.

Un'attenta revisione in questa fase consente di evitare costose rielaborazioni durante le fasi di implementazione e convalida.

Errori di compilazione e avvio

Se l'applicazione trasformata non riesce a compilare o avviare, usare l'approccio seguente:

  1. Controllare l'artefatto del report del tester (ad esempio, t21-tester-report.md) per l'output del build e le tracce dello stack.
  2. Cercare il tipo di eccezione o il messaggio di errore nell'artefatto per identificare la causa radice.
  3. Se l'agente ha creato iterazioni di correzione (ad esempio, t21.1, t21.3), esaminare tali artefatti per vedere quali modifiche sono state tentate.

Le cause radice comuni includono conflitti di denominazione tra classi legacy e nuove generate, configurazioni del profilo Spring non corrette e dipendenze mancanti o in conflitto in pom.xml. Ad esempio, se i controller legacy e moderni condividono lo stesso nome di classe, Spring genera un'eccezione ConflictingBeanDefinitionException all'avvio.

Errori di esecuzione

Se l'applicazione viene avviata ma le chiamate API restituiscono errori (ad esempio 500 o 400 risposte), usare l'approccio seguente:

  1. Controllare l'artefatto del report del tester per gli endpoint non riusciti e i messaggi di errore associati.
  2. Esaminare l'artefatto dei risultati di sicurezza (ad esempio, t20-security-findings.md) per individuare i problemi di configurazione.
  3. Esaminare le classi di entità generate e il codice del controller per verificare la mancata corrispondenza tra lo schema del database e i mapping ORM.

Le cause principali comuni includono conflitti di parole chiave riservate del database nelle @Column annotazioni, disallineamenti tra tipi di campo DTO e tipi di campo di entità e mancanza di annotazioni di convalida negli oggetti della richiesta.

Difetti nei gate di qualità e iterazioni

L'agente applica diversi controlli di qualità durante il processo di ri-architettura. Quando un gate ha esito negativo, l'agente crea automaticamente le attività di correzione e ritenta la convalida. Gli errori comuni del gate includono:

  • Revisione dell'architettura: l'agente verifica che l'implementazione corrisponda ai contratti API progettati, alle strutture DTO e ai mapping degli endpoint. Gli errori in genere comportano endpoint mancanti, campi rinominati o annotazioni di convalida mancanti. Esaminare l'artefatto del report dell'architetto, ad esempio, t19-architect-review.md per individuare risultati specifici.
  • Verifica della conformità: l'agente verifica che l'implementazione soddisfi tutti i principi definiti nella costituzione iniziale. Un errore comune è la mancanza di test end-to-end a livello di browser quando i requisiti li richiedono. Esaminare l'artefatto di revisione responsabile del team (ad esempio, t22-teamlead-review.md) per identificare quali principi non sono stati soddisfatti.
  • Convalida della parità delle funzionalità: l'agente verifica che siano implementati tutti i requisiti catalogati. Una approvazione parziale indica che funzionalità specifiche sono incomplete, ad esempio la mancata convalida tra campi, come assicurarsi che fromDate sia prima di toDate. Esaminare l'artefatto di approvazione da parte del PM (ad esempio, t23-pm-signoff.md) per la scomposizione requisito per requisito.

Se l'agente raggiunge il limite di iterazione senza risolvere tutti i problemi, esaminare i file degli artefatti più recenti per comprendere le lacune rimanenti e applicare correzioni manuali.

Prerequisiti di convalida del runtime

L'agente esegue passaggi di convalida del runtime facoltativi che dipendono da strumenti esterni. Se uno strumento non è disponibile, il passaggio corrispondente viene ignorato:

  • Python non installato: il passaggio del grafico delle informazioni viene ignorato. L'agente può comunque eseguire la ri-architettura, ma potrebbe avere meno contesto sulla struttura del progetto. Installare Python 3.7 o versione successiva e assicurarsi che python3 sia disponibile nel PATH.
  • Node.js non installato: i test end-to-end a livello di browser Playwright vengono ignorati. L'agente esegue comunque test di integrazione tramite Maven. Installare Node.js 18 o versione successiva per abilitare i test del browser.
  • Docker non disponibile: la convalida del runtime (avvio dell'applicazione in un contenitore e la verifica della gestione delle richieste) viene ignorata. L'agente si basa invece sui test di unità e integrazione. Installare e avviare Docker Desktop per abilitare questo passaggio.

Limitazioni

Tenere presenti le limitazioni seguenti:

  • I progetti complessi con framework legacy ad accoppiamento avanzato potrebbero richiedere più iterazioni.
  • È consigliabile esaminare attentamente il codice generato prima di eseguire il commit delle modifiche.

Inviare commenti

Se si hanno commenti e suggerimenti sulla funzionalità di nuova architettura, creare un problema nel repository github-copilot-appmod o usare il modulo di feedback sulla modernizzazione GitHub Copilot.

Vedere anche

Panoramica di GitHub Copilot per la modernizzazione di Java

  • Last updated on