Rediseñar proyectos mediante la modernización de GitHub Copilot

En este artículo se describe cómo usar la característica de re-arquitectura en la modernización de GitHub Copilot para reescribir proyectos de frameworks heredados a arquitecturas modernas, como de Struts a Spring MVC.

Visión general

La característica de nueva arquitectura permite transformar un proyecto completo de un marco heredado a una arquitectura moderna mediante un flujo de trabajo multiagente con tecnología de inteligencia artificial. En lugar de una migración manual, archivo por archivo, describe la transformación deseada en lenguaje natural, y los agentes de modernización se encargan del análisis, la planificación y la generación de código.

Entre los escenarios comunes de rearquitectura se incluyen los siguientes:

• Migración de Struts a Spring MVC
• De Struts a Spring Boot
• JSP a Thymeleaf
• EJB a Spring Boot
• Aplicaciones de WebSphere para Spring Boot
• Aplicaciones heredadas basadas en servlets a arquitecturas modernas basadas en Spring
• aplicaciones de escritorio de Windows Forms (WinForms) en aplicaciones web de Angular
• aplicaciones front-end de ASP.NET MVC a aplicaciones web de Angular

Prerrequisitos

• Visual Studio Code con la extensión de actualización de GitHub Copilot instalada.
• Una suscripción de GitHub Copilot. Para obtener más información, consulte Copilot plans.
• (Opcional) Python 3.7 o posterior para crear un grafo de conocimiento, lo que proporciona al agente una comprensión más clara de la estructura del proyecto durante el proceso de reescritura. Si Python no está disponible, se omite el paso del grafo de conocimiento.
• (Opcional) Node.js 18 o posterior para ejecutar pruebas de Playwright como parte de la validación en tiempo de ejecución. Si Node.js no está disponible, se omite el paso de prueba de Playwright.
• (Opcional) Docker Desktop para la validación en tiempo de ejecución. Si Docker no está disponible, se omite el paso de validación en tiempo de ejecución.

Uso del agente de restructuración

Usa el agente modernize en el panel de GitHub Copilot Chat.

Siga estos pasos para volver a diseñar un proyecto:

1. Abra el proyecto en Visual Studio Code.

2. Abra el panel GitHub Copilot Chat.

3. Seleccione el agente modernize de la lista de agentes.

4. Describir la transformación que desea realizar. Por ejemplo:

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

El agente coordina un equipo de varios agentes que realiza los pasos siguientes:

1. Análisis : examina el código base existente, identifica los patrones de marco, las dependencias y los límites del módulo.
2. Planificación : genera un plan de implementación estructurado con tareas ordenadas y rastreabilidad de requisitos.
3. Ejecución : aplica transformaciones de código después del plan, con comprobaciones de validación en cada paso.

Proporcionar más contexto

Puede mejorar los resultados de la transformación proporcionando contexto adicional en el mensaje:

• Especifique las versiones del marco de destino, por ejemplo, "Use Spring Boot 3.2 y Java 21".
• Vínculos de documentación de referencia o guías de migración.
• Describir patrones o convenciones específicos de la organización.
• Indique qué módulos o paquetes se van a priorizar.

Por ejemplo:

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.

Solucionar problemas comunes

Durante el proceso de nueva arquitectura, el agente genera artefactos en el .github/modernize/ directorio del proyecto. Use estos artefactos para diagnosticar problemas cuando surjan.

Revisión de artefactos generados

El .github/modernize/rearchitecture directorio contiene los siguientes recursos clave:

• board.md - Panel de tareas que realiza un seguimiento de cada fase y su estado. Compruebe este archivo para ver qué tareas fueron aprobadas, fallaron o requieren iteraciones.
• artifacts/ - Informes detallados de cada tarea. Los archivos siguen una convención de nomenclatura como t21-tester-report.md para el informe de prueba inicial o t21.2-tester-report.md para una iteración de reintento.
• learn.md - Una base de conocimiento acumulativa de detecciones, hallazgos de errores y técnicas registradas por cada rol durante la ejecución de la tarea. Compruebe este archivo para obtener información sobre los problemas detectados por el agente y cómo los resolvió.
• team/ - Cartas específicas del rol que definen las responsabilidades de cada agente.

Cuando se produce un error en una puerta de calidad, el agente crea artefactos de iteración (por ejemplo, t21.1, t21.2) que documentan los intentos de corrección. Busque estas iteraciones numeradas para comprender cómo se detectó y resolvió un problema.

Revisión del análisis y el plan

Antes de que el agente empiece a escribir código, genera artefactos de análisis y planificación que debe revisar. Estos artefactos proporcionan visibilidad sobre lo que el agente comprendió acerca de tu proyecto y lo que pretende construir.

Los artefactos de análisis incluyen:

• Resumen de la arquitectura: información general sobre la pila tecnológica existente, la estructura del proyecto, el modelo de datos y los puntos de integración. Compruebe este resumen para comprobar que el agente identificó correctamente los componentes clave del proyecto. Busque archivos como artifacts/t2-architect-architecture-summary.md, artifacts/t2-architect-tech-stack.mdy artifacts/t2-architect-data-model.md.
• Inventario de características: un catálogo de todas las características de la aplicación original, cada una ha sido asignada un identificador de requisito (por ejemplo, REQ-001). Compruebe que esta lista está completa y precisa. Busque artifacts/t3-pm-spec.md.
• Diseño de la arquitectura de destino: las opciones propuestas de contratos de API, estructura de módulos y tecnología para la nueva aplicación. Busque archivos como artifacts/t5-architect-api-contracts.md y artifacts/t5-architect-integration.md.

Los artefactos de planeación incluyen:

• Plan de implementación: una lista ordenada de tareas con dependencias, agrupadas en fases. Cada tarea vuelve a asignarse a uno o varios requisitos del inventario de características. Busque artifacts/t7-teamlead-plan.md.
• Estrategia de pruebas: el enfoque planeado para pruebas unitarias, pruebas de integración y pruebas de un extremo a otro. Busque artifacts/t7-teamlead-testing-strategy.md.

El agente se detiene después de generar estos artefactos y espera la confirmación. Use esta oportunidad para:

• Compruebe que no falta ninguna característica del inventario.
• Compruebe que la arquitectura de destino coincida con sus expectativas.
• Ajuste las prioridades de tareas o agregue restricciones antes de que comience la implementación.

Una revisión cuidadosa en esta fase ayuda a evitar un trabajo costoso durante las fases de implementación y validación.

Errores de compilación e inicio

Si la aplicación transformada no se puede compilar o iniciar, use el siguiente enfoque:

1. Compruebe el artefacto del informe del tester (por ejemplo, t21-tester-report.md) para consultar la salida de compilación y los rastros de pila.
2. Busque el tipo de excepción o el mensaje de error en el artefacto para identificar la causa principal.
3. Si el agente creó iteraciones de corrección (por ejemplo, t21.1, t21.3), revise los artefactos para ver los cambios que se realizaron.

Entre las causas principales comunes se incluyen conflictos de nomenclatura entre clases heredadas y recién generadas, configuraciones de perfil de Spring incorrectas y dependencias que faltan o entran en conflicto en pom.xml. Por ejemplo, si los controladores heredados y modernos comparten el mismo nombre de clase, Spring lanza una ConflictingBeanDefinitionException excepción al inicio.

Errores en tiempo de ejecución

Si la aplicación se inicia, pero las llamadas API devuelven errores (como 500 o 400 respuestas), use el siguiente enfoque:

1. Compruebe el artefacto del informe del tester sobre los endpoints que fallaron y los mensajes de error asociados.
2. Revise el artefacto de búsqueda de seguridad (por ejemplo, t20-security-findings.md) para ver los problemas de configuración.
3. Inspeccione las clases de entidad generadas y el código del controlador para detectar errores de coincidencia entre el esquema de base de datos y las asignaciones de ORM.

Entre las causas principales comunes se incluyen conflictos de palabras clave reservadas de base de datos en @Column anotaciones, discrepancias entre los tipos de campo DTO y los tipos de campo de entidad y las anotaciones de validación que faltan en los objetos de solicitud.

Fallos e iteraciones en el control de calidad

El agente impone varios puntos de control de calidad durante el proceso de rearquitectura. Cuando se produce un error en una puerta, el agente crea automáticamente tareas de corrección y reintentos de validación. Entre los errores de puerta comunes se incluyen:

• Revisión de la arquitectura: el agente comprueba que la implementación coincide con los contratos de API diseñados, las estructuras DTO y las asignaciones de puntos de conexión. Los errores suelen implicar puntos de conexión que faltan, campos cambiados de nombre o anotaciones de validación que faltan. Revisar el artefacto del informe del arquitecto (por ejemplo, t19-architect-review.md) para identificar conclusiones específicas.
• Revisión de conformidad: el agente comprueba que la implementación cumple todos los principios definidos en la constitución inicial. Faltan pruebas de principio a fin a nivel de navegador cuando la constitución las requiere. Revise el artefacto de revisión del responsable del equipo (por ejemplo, t22-teamlead-review.md) para identificar qué principios no se han cumplido.
• Aprobación de paridad de características: el agente comprueba que se implementan todos los requisitos catalogados. Una aprobación parcial significa que las características específicas están incompletas, por ejemplo, la falta de validación entre campos, como asegurarse de que fromDate sea anterior a toDate. Revise el artefacto de cierre de sesión de PM (por ejemplo, t23-pm-signoff.md) para obtener el desglose de requisitos por requisito.

Si el agente alcanza su límite de iteración sin resolver todos los problemas, revise los archivos de artefacto más recientes para comprender las lagunas restantes y aplicar correcciones manuales.

Requisitos previos de validación en tiempo de ejecución

El agente realiza pasos opcionales de validación en tiempo de ejecución que dependen de herramientas externas. Si una herramienta no está disponible, se omite el paso correspondiente:

• Python no instalado: se omite el paso del grafo de conocimiento. El agente todavía puede realizar la nueva arquitectura, pero puede tener menos contexto sobre la estructura del proyecto. Instale Python 3.7 o posterior y asegúrese de que python3 esté disponible en path.
• Node.js no instalado: se omiten las pruebas de nivel de navegador de Playwright de extremo a extremo. El agente todavía ejecuta pruebas de integración a través de Maven. Instale Node.js 18 o posterior para habilitar las pruebas del explorador.
• Docker no disponible: se omite la validación en tiempo de ejecución (iniciando la aplicación en un contenedor y comprobando que atiende las solicitudes). El agente se basa en pruebas unitarias e de integración en su lugar. Instale e inicie Docker Desktop para habilitar este paso.

Limitaciones

Tenga en cuenta las siguientes limitaciones:

• Los proyectos complejos con marcos heredados profundamente acoplados pueden requerir varias iteraciones.
• Debe revisar cuidadosamente el código generado antes de confirmar los cambios.

Enviar comentarios

Si tiene algún comentario sobre la característica de nueva arquitectura, cree un problema en el repositorio github-copilot-appmod o use el formulario de comentarios de modernización GitHub Copilot.

Consulte también

Descripción general de la modernización de Java con GitHub Copilot