Ponowne projektowanie projektów przy użyciu modernizacji GitHub Copilot

W tym artykule opisano sposób używania funkcji przebudowy architektury w GitHub Copilot w ramach modernizacji w celu przepisania projektów ze starszych struktur do nowoczesnych architektur, takich jak Struts do Spring MVC.

Przegląd

Funkcja ponownej architektury umożliwia przekształcenie całego projektu ze starszej platformy na nowoczesną architekturę przy użyciu przepływu pracy wieloa agenta opartego na sztucznej inteligencji. Zamiast ręcznej migracji plików po plikach opisz żądaną transformację w języku naturalnym, a agenci modernizacji obsługują analizę, planowanie i generowanie kodu.

Typowe scenariusze ponownej architektury obejmują:

• Struts do Spring MVC
• Migracja z Struts do Spring Boot
• JSP to Thymeleaf
• z EJB do Spring Boot
• Aplikacje WebSphere do platformy Spring Boot
• Starsze aplikacje oparte na serwletach do nowoczesnych architektur opartych na platformie Spring
• aplikacje klasyczne Windows Forms (WinForms) do internetowych aplikacji Angular
• z aplikacji frontendowych ASP.NET MVC do aplikacji internetowych Angular

Wymagania wstępne

• Visual Studio Code z zainstalowanym rozszerzeniem GitHub Copilot.
• Subskrypcja GitHub Copilot. Aby uzyskać więcej informacji, zobacz Copilot plans.
• (Opcjonalnie) Python 3.7 lub nowszy do tworzenia grafu wiedzy, co daje agentowi jaśniejsze zrozumienie struktury projektu podczas procesu ponownego pisania. Jeśli Python nie jest dostępna, krok grafu wiedzy zostanie pominięty.
• (Opcjonalnie) Node.js 18 lub nowszy do uruchamiania testów Playwright jako część walidacji środowiska uruchomieniowego. Jeśli Node.js nie jest dostępna, krok testu dramaturgu zostanie pominięty.
• (Opcjonalnie) Docker Desktop na potrzeby walidacji środowiska uruchomieniowego. Jeśli platforma Docker nie jest dostępna, krok weryfikacji środowiska uruchomieniowego zostanie pominięty.

Użyj agenta przeprojektowania architektury

Użyj agenta modernizacji w panelu usługi GitHub Copilot Chat.

Wykonaj następujące kroki, aby ponownie zaprojektować projekt:

1. Otwórz projekt w Visual Studio Code.

2. Otwórz panel GitHub Copilot Chat.

3. Wybierz agenta modernizacji z listy agentów.

4. Opisz transformację, którą chcesz wykonać. Przykład:

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

Agent koordynuje zespół z wieloma agentami, który wykonuje następujące kroki:

1. Analiza — analizuje istniejącą bazę kodu, identyfikuje wzorce struktury, zależności i granice modułów.
2. Planowanie — generuje ustrukturyzowany plan implementacji z uporządkowanymi zadaniami i możliwościami śledzenia wymagań.
3. Wykonanie — stosuje przekształcenia kodu zgodnie z planem z sprawdzaniem poprawności w każdym kroku.

Podaj więcej kontekstu

Wyniki przekształcania można poprawić, podając dodatkowy kontekst w wierszu polecenia:

• Określ wersje platformy docelowej, na przykład "Użyj platformy Spring Boot 3.2 i Java 21".
• Linki do dokumentacji referencyjnej lub przewodniki dotyczące migracji.
• Opis wzorców lub konwencji specyficznych dla organizacji.
• Określ, które moduły lub pakiety mają być priorytetowe.

Przykład:

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.

Rozwiązywanie typowych problemów

Podczas procesu przeprojektowania architektury agent generuje artefakty w .github/modernize/ katalogu projektu. Użyj tych artefaktów, aby zdiagnozować problemy, gdy wystąpią.

Przeglądanie wygenerowanych artefaktów

Katalog .github/modernize/rearchitecture zawiera następujące kluczowe zasoby:

• board.md - Tablica zadań, która śledzi każdą fazę i jej stan. Sprawdź ten plik, aby sprawdzić, które zadania przeszły, nie powiodły się lub wymagały iteracji.
• artifacts/ — Szczegółowe raporty z każdego zadania. Pliki są zgodne z konwencją nazewnictwa, taką jak t21-tester-report.md dla początkowego raportu testowego lub t21.2-tester-report.md dla iteracji ponownej.
• learn.md — Skumulowana baza wiedzy dotycząca odnajdywania, ustaleń błędów i technik rejestrowanych przez każdą rolę podczas wykonywania zadania. Sprawdź ten plik, aby uzyskać szczegółowe informacje na temat napotkanych przez agenta problemów i sposobu ich rozwiązania.
• team/ - Karty specyficzne dla ról, które definiują obowiązki każdego agenta.

Gdy próg jakości zakończy się niepowodzeniem, agent tworzy artefakty iteracji (na przykład t21.1, t21.2), które dokumentują próby naprawienia. Poszukaj tych numerowanych iteracji, aby dowiedzieć się, jak wykryto i rozwiązano problem.

Przegląd analizy i planu

Przed rozpoczęciem pisania kodu agent tworzy artefakty analizy i planowania, które należy przejrzeć. Artefakty te zapewniają wgląd w to, co agent zrozumiał o Twoim projekcie i co zamierza zbudować.

Artefakty analizy obejmują:

• Podsumowanie architektury: Omówienie istniejącego stosu technologicznego, struktury projektu, modelu danych i punktów integracji. Sprawdź to podsumowanie, aby sprawdzić, czy agent prawidłowo zidentyfikował kluczowe składniki projektu. Wyszukaj pliki, takie jak artifacts/t2-architect-architecture-summary.md, artifacts/t2-architect-tech-stack.mdi artifacts/t2-architect-data-model.md.
• Spis funkcji: wykaz wszystkich funkcji w oryginalnej aplikacji, z których każdy ma przypisany identyfikator wymagania (na przykład REQ-001). Sprawdź, czy ta lista jest kompletna i dokładna. Poszukaj artifacts/t3-pm-spec.md.
• Projekt architektury docelowej: proponowane kontrakty interfejsu API, struktura modułu i opcje technologii dla nowej aplikacji. Wyszukaj pliki, takie jak artifacts/t5-architect-api-contracts.md i artifacts/t5-architect-integration.md.

Artefakty planowania obejmują:

• Plan implementacji: uporządkowana lista zadań z zależnościami pogrupowana w fazy. Każde zadanie mapuje się z powrotem na co najmniej jedno wymaganie ze spisu funkcji. Poszukaj artifacts/t7-teamlead-plan.md.
• Strategia testowania: planowane podejście do testów jednostkowych, testów integracyjnych i testów całościowych. Poszukaj artifacts/t7-teamlead-testing-strategy.md.

Agent wstrzymuje się po wygenerowaniu tych artefaktów i czeka na potwierdzenie. Skorzystaj z tej okazji, aby:

• Sprawdź, czy w spisie nie brakuje żadnych funkcji.
• Sprawdź, czy architektura docelowa jest zgodna z oczekiwaniami.
• Dostosuj priorytety zadań lub dodaj ograniczenia przed rozpoczęciem implementacji.

Staranne przeglądy na tym etapie pomagają uniknąć kosztownych ponownych prac podczas faz implementacji i walidacji.

Błędy kompilacji i uruchamiania

Jeśli przekształcona aplikacja nie może skompilować lub uruchomić, użyj następującego podejścia:

1. Sprawdź artefakt raportu testera (na przykład t21-tester-report.md) pod kątem danych wyjściowych kompilacji i śladów stosu.
2. Wyszukaj typ wyjątku lub komunikat o błędzie w artefaktzie, aby zidentyfikować główną przyczynę.
3. Jeśli agent utworzył iteracje poprawek (na przykład t21.1, t21.3), przejrzyj te artefakty, aby sprawdzić, jakie zmiany zostały podjęte.

Typowe główne przyczyny obejmują kolizje nazewnictwa między starszymi i nowo wygenerowanymi klasami, niepoprawnymi konfiguracjami profilu Spring oraz brakującymi lub powodującymi konflikt zależności w programie pom.xml. Jeśli na przykład starsze i nowoczesne kontrolery mają taką samą nazwę klasy, platforma Spring zgłasza błąd podczas uruchamiania ConflictingBeanDefinitionException .

Błędy środowiska uruchomieniowego

Jeśli aplikacja zostanie uruchomiona, ale interfejs API wywołuje błędy zwracane (takie jak 500 lub 400 odpowiedzi), użyj następującego podejścia:

1. Sprawdź artefakt raportu testera, dla którego punkty końcowe zakończyły się niepowodzeniem i skojarzonymi komunikatami o błędach.
2. Przejrzyj artefakt ustaleń zabezpieczeń (na przykład t20-security-findings.md) pod kątem problemów z konfiguracją.
3. Sprawdź wygenerowane klasy jednostek i kod kontrolera pod kątem niezgodności między schematem bazy danych a mapowaniami ORM.

Typowe przyczyny obejmują konflikty słów kluczowych zarezerwowanych dla bazy danych w adnotacjach @Column, niezgodności między typami pól DTO a typami pól jednostek oraz brak adnotacji walidacji na obiektach żądań.

Błędy przejścia bramy jakości i iteracje

Agent wymusza kilka etapów kontroli jakości podczas procesu ponownej architektury. Gdy brama ulegnie awarii, agent automatycznie tworzy zadania naprawcze i ponownie próbuje zweryfikować. Typowe błędy bramy obejmują:

• Przegląd architektury: agent sprawdza, czy implementacja jest zgodna z zaprojektowanymi kontraktami interfejsu API, strukturami DTO i mapowaniami punktów końcowych. Błędy zwykle obejmują brakujące punkty końcowe, zmienione pola lub brakujące adnotacje weryfikacji. Przejrzyj artefakt raportu architektonicznego (na przykład t19-architect-review.md) pod kątem konkretnych wyników.
• Przegląd zgodności: agent sprawdza, czy implementacja spełnia wszystkie zasady określone w początkowej konstytucji. Typowy błąd polega na braku end-to-end testów na poziomie przeglądarki, gdy wymagania tego wymagają. Przejrzyj artefakt przeglądu prowadzącego zespołu (na przykład t22-teamlead-review.md), aby określić, które zasady nie zostały spełnione.
• Zatwierdzenie zgodności funkcji: agent sprawdza, czy zostały zaimplementowane wszystkie skatalogowane wymagania. Częściowe zatwierdzenie oznacza, że określone funkcje są niekompletne, na przykład brak weryfikacji krzyżowej pól, takiej jak zapewnienie, że fromDate jest przed toDate. Zapoznaj się z artefaktem akceptacji PM (na przykład t23-pm-signoff.md) dla podziału na poszczególne wymagania.

Jeśli agent osiągnie limit iteracji bez rozwiązywania wszystkich problemów, przejrzyj najnowsze pliki artefaktów, aby zrozumieć pozostałe luki i zastosować poprawki ręczne.

Wymagania wstępne dotyczące walidacji środowiska uruchomieniowego

Agent wykonuje opcjonalne kroki weryfikacji środowiska uruchomieniowego, które zależą od narzędzi zewnętrznych. Jeśli narzędzie nie jest dostępne, odpowiedni krok zostanie pominięty:

• Python nie zainstalowano: Krok grafu wiedzy został pominięty. Agent może nadal przeprowadzać przebudowę architektury, ale może mieć mniej informacji o strukturze Twojego projektu. Zainstaluj Python 3.7 lub nowszy i upewnij się, że python3 jest dostępna w ścieżce.
• Node.js nie jest zainstalowany: Testy end-to-end na poziomie przeglądarki Playwright są pomijane. Agent nadal uruchamia testy integracji za pośrednictwem narzędzia Maven. Zainstaluj Node.js 18 lub nowszych, aby włączyć testowanie przeglądarki.
• Platforma Docker jest niedostępna: sprawdzanie poprawności środowiska uruchomieniowego (uruchamianie aplikacji w kontenerze i weryfikowanie obsługi żądań) zostało pominięte. Agent opiera się zamiast tego na testach jednostkowych i integracyjnych. Zainstaluj i uruchom program Docker Desktop, aby włączyć ten krok.

Ograniczenia

Należy pamiętać o następujących ograniczeniach:

• Złożone projekty z głęboko powiązanymi starszymi strukturami mogą wymagać wielu iteracji.
• Przed zatwierdzeniem zmian należy dokładnie przejrzeć wygenerowany kod.

Prześlij opinię

Jeśli masz jakiekolwiek opinie na temat funkcji ponownej architektury, utwórz problem w repozytorium github-copilot-appmod lub użyj formularza opinii o modernizacji GitHub Copilot.

Zobacz też

Omówienie modernizacji aplikacji Java przy użyciu GitHub Copilot