Перепроектировать проекты с помощью модернизации GitHub Copilot

В этой статье описывается, как использовать функцию реархитектурирования в инструменте модернизации GitHub Copilot для переписывания проектов с устаревших фреймворков на современные архитектуры, такие как переход от Struts к Spring MVC.

Обзор

Функция повторной архитектуры позволяет преобразовать весь проект из устаревшей платформы в современную архитектуру с помощью рабочего процесса с поддержкой искусственного интеллекта с несколькими агентами. Вместо ручной миграции по файлам опишите требуемое преобразование на естественном языке, а агенты модернизации обрабатывают анализ, планирование и создание кода.

Ниже приведены распространенные сценарии повторной архитектуры:

  • Подстроки в Spring MVC
  • От Struts к Spring Boot
  • Переход с JSP на Thymeleaf
  • Переход с EJB на Spring Boot
  • Приложения WebSphere для Spring Boot
  • Устаревшие приложения на основе сервлетов на новые архитектуры на базе Spring
  • настольные приложения Windows Forms (WinForms) в веб-приложения Angular
  • ASP.NET MVC интерфейсные приложения для веб-приложений Angular

Необходимые условия

  • Visual Studio Code с установленным расширением GitHub Copilot modernization.
  • Подписка на GitHub Copilot. Дополнительные сведения см. в планах Copilot.
  • (Необязательно) Python 3.7 или более поздней версии для создания графа знаний, что дает агенту более четкое представление о структуре проекта во время процесса перезаписи. Если Python недоступно, шаг графа знаний пропускается.
  • (Необязательно) Node.js 18 или более поздней версии для выполнения тестов Playwright в рамках проверки среды выполнения. Если Node.js недоступно, шаг теста Playwright пропускается.
  • (Необязательно) Docker Desktop для проверки среды выполнения. Если Docker недоступен, шаг проверки среды выполнения пропускается.

Используйте агент реархитектуры

Используйте агент модернизации на панели Copilot Chat GitHub.

Чтобы перепроектировать проект, выполните следующие действия.

  1. Откройте проект в Visual Studio Code.

  2. Откройте панель GitHub Copilot Chat.

  3. Выберите агент modernize из списка агентов.

  4. Опишите преобразование, которое требуется выполнить. Рассмотрим пример.

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

Агент координирует команду с несколькими агентами, которая выполняет следующие действия:

  1. Анализ — проверяет существующую базу кода, определяя шаблоны платформы, зависимости и границы модуля.
  2. Планирование — создает структурированный план реализации с упорядоченными задачами и возможностью трассировки требований.
  3. Выполнение — применяет преобразования кода после плана с проверкой на каждом шаге.

Это важно

После завершения анализа и планирования агент приостанавливает и запрашивает подтверждение перед началом создания кода. Внимательно просмотрите план на этом этапе. Вы можете запросить изменения плана, настроить приоритеты или добавить ограничения, прежде чем агент переходит к реализации.

Укажите больше контекста

Вы можете улучшить результаты преобразования, предоставив дополнительный контекст в запросе:

  • Укажите версии целевой платформы, например "Использовать Spring Boot 3.2 и Java 21".
  • Ссылки на справочную документацию или руководства по миграции.
  • Описание шаблонов или соглашений, относящихся к организации.
  • Укажите, какие модули или пакеты следует выделить в качестве приоритетных.

Рассмотрим пример.

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.

Устранение распространенных неполадок

В процессе перестройки архитектуры агент создает артефакты в .github/modernize/ каталоге проекта. Используйте эти артефакты для диагностики проблем при возникновении.

Проверка созданных артефактов

Каталог .github/modernize/rearchitecture содержит следующие ключевые ресурсы:

  • board.md — Доска задач, отслеживающая каждый этап и его состояние. Проверьте этот файл, чтобы узнать, какие задачи прошли, завершились сбоем или требовали итераций.
  • artifacts/ — Подробные отчеты из каждой задачи. Файлы следуют соглашению об именовании, например t21-tester-report.md для первоначального тестового отчета или t21.2-tester-report.md для итерации повторных попыток.
  • learn.md — совокупная база знаний об обнаружениях, результатах ошибок и методах, зарегистрированных каждой ролью во время выполнения задачи. Проверьте этот файл, чтобы получить аналитические сведения о проблемах, обнаруженных агентом, и о том, как он их устранил.
  • team/ — Регламенты, определяющие обязанности каждого агента в зависимости от их роли.

При сбое ворот качества агент создает итерационные артефакты (например, t21.1, t21.2), которые документируют попытки исправления. Найдите эти нумерованные итерации, чтобы понять, как обнаружена и устранена проблема.

Рассмотрите анализ и план

Прежде чем агент начнет писать код, он создает артефакты анализа и планирования, которые необходимо просмотреть. Эти артефакты дают вам представление о том, что агент понял о проекте и о том, что он намерен построить.

К артефактам анализа относятся:

  • Сводка по архитектуре. Общие сведения о существующем стеке технологий, структуре проекта, модели данных и точках интеграции. Проверьте эту сводку, чтобы убедиться, что агент правильно определил ключевые компоненты вашего проекта. Найдите такие файлы, как artifacts/t2-architect-architecture-summary.md, artifacts/t2-architect-tech-stack.mdи artifacts/t2-architect-data-model.md.
  • Инвентаризация компонентов: каталог всех функций в исходном приложении, каждый присваивает идентификатор требования (например, REQ-001). Убедитесь, что этот список является полным и точным. Найдите artifacts/t3-pm-spec.md.
  • Проектирование целевой архитектуры: предлагаемые контракты API, структура модуля и варианты технологий для нового приложения. Поиск таких файлов, как artifacts/t5-architect-api-contracts.md и artifacts/t5-architect-integration.md.

К артефактам планирования относятся:

  • План реализации: упорядоченный список задач с зависимостями, сгруппирован на этапы. Каждая задача сопоставляется с одним или несколькими требованиями из инвентаризации компонентов. Найдите artifacts/t7-teamlead-plan.md.
  • Стратегия тестирования: запланированный подход для модульных тестов, тестов интеграции и комплексных тестов. Найдите artifacts/t7-teamlead-testing-strategy.md.

Агент делает паузу после создания этих артефактов и ждёт вашего подтверждения. Используйте эту возможность:

  • Убедитесь, что ни одна функция не отсутствует в списке.
  • Убедитесь, что целевая архитектура соответствует вашим ожиданиям.
  • Настройте приоритеты задач или добавьте ограничения перед началом реализации.

Тщательный обзор на этом этапе помогает избежать дорогостоящих переработок во время реализации и проверки.

Сбои сборки и запуска

Если преобразованное приложение не удалось скомпилировать или запустить, используйте следующий подход:

  1. Проверьте артефакт отчета тестировщика (например, t21-tester-report.md) для выходных данных сборки и трассировки стека.
  2. Найдите тип исключения или сообщение об ошибке в артефакте, чтобы определить первопричину.
  3. Если агент создал итерации исправления (например, t21.1, t21.3), просмотрите эти артефакты, чтобы узнать, какие изменения пытались внести.

Распространенные первопричины включают столкновения именования между устаревшими и недавно созданными классами, неправильную конфигурацию профилей Spring, а также отсутствие или конфликтующие зависимости в pom.xml. Например, если устаревшие и современные контроллеры имеют одно и то же имя класса, Spring создает ConflictingBeanDefinitionException исключение при запуске.

Ошибки среды выполнения

Если приложение запускается, но вызовы API возвращают ошибки (например, 500 или 400 ответов), используйте следующий подход:

  1. Проверьте артефакт отчета тестировщика, чтобы определить, в каких конечных точках произошел сбой, и связанные с ними сообщения об ошибках.
  2. Просмотрите артефакт результатов безопасности (например, t20-security-findings.md) для выявления проблем с конфигурацией.
  3. Проверьте созданные классы сущностей и код контроллера для несоответствия между схемой базы данных и сопоставлениями ORM.

Распространенные первопричины включают конфликты зарезервированных ключевых слов базы данных в @Column аннотациях, несоответствия между типами полей DTO и типами полей сущностей, а также отсутствие аннотаций валидации на объектах запроса.

Несоответствия контрольных точек качества и итерации

Агент применяет несколько контрольных точек качества в процессе реархитектурирования. Если шлюз завершается сбоем, агент автоматически создает задачи по исправлению и повторно выполняет валидацию. Распространенные сбои ворот включают:

  • Проверка архитектуры: агент проверяет, соответствует ли реализация разработанным контрактам API, структурам DTO и сопоставлениям конечных точек. Ошибки обычно включают отсутствующие конечные точки, переименованные поля или отсутствующие заметки проверки. Просмотрите артефакт отчета архитектора (например, t19-architect-review.md), чтобы получить конкретную информацию.
  • Проверка соответствия: агент проверяет, соответствует ли реализация всем принципам, определенным в первоначальной конституции. Распространенной ошибкой является отсутствие сквозных тестов на уровне браузера, когда их требуют требования. Просмотрите артефакт проверки руководителя группы (например, t22-teamlead-review.md), чтобы определить, какие принципы не удовлетворены.
  • Подтверждение равенства функций: агент проверяет, все ли требования, внесённые в каталог, реализованы. Частичное одобрение означает, что определенные функции являются неполными, например, отсутствие межполевой валидации, такое как обеспечение того, что fromDate идет перед toDate. Просмотрите артефакт утверждения PM (например, t23-pm-signoff.md) для анализа каждого требования отдельно.

Если агент достигает предела итерации без устранения всех проблем, просмотрите последние файлы артефактов, чтобы понять оставшиеся пробелы и применить исправления вручную.

Предварительные требования для валидации среды исполнения

Агент выполняет необязательные действия проверки среды выполнения, зависящие от внешних средств. Если средство недоступно, соответствующий шаг пропускается:

  • Python не установлен: шаг графа знаний пропущен. Агент по-прежнему может проводить реорганизацию архитектуры, но может иметь меньше представления о структуре вашего проекта. Установите Python 3.7 или более поздней версии и убедитесь, что python3 доступен в path.
  • Node.js не установлено: сквозные тесты на уровне браузера Playwright пропускаются. Агент по-прежнему выполняет тесты интеграции через Maven. Установите Node.js 18 или более поздней версии, чтобы включить тестирование браузера.
  • Docker недоступен: проверка среды выполнения (запуск приложения в контейнере и проверка его обслуживания) пропускается. Вместо этого агент использует модульные и интеграционные тесты. Установите и запустите Docker Desktop, чтобы включить этот шаг.

Ограничения

Необходимо учитывать следующие ограничения.

  • Для сложных проектов с глубоко связанных устаревших платформ может потребоваться несколько итераций.
  • Перед фиксацией изменений необходимо тщательно просмотреть созданный код.

Предоставьте отзыв

Если у вас есть отзывы о функции повторной архитектуры, создайте проблему в репозитории github-copilot-appmod или используйте форму обратной связи о модернизации GitHub Copilot.

См. также

Обзор модернизации Java с помощью GitHub Copilot

  • Последнее обновление: