Projektek újratervezése a GitHub Copilot használatával végzett modernizációval

Ez a cikk azt ismerteti, hogyan használható az újraarchitektúra funkció a GitHub Copilot modernizálásban projektek átírására az örökölt keretrendszerekből a modern architektúrákba, például a Struts-ből a Spring MVC-be.

Áttekintés

Az újraarchitektúra funkció lehetővé teszi egy teljes projekt egy örökölt keretrendszerből egy modern architektúrává való átalakítását egy AI-alapú többügynökös munkafolyamat használatával. A manuális, fájlonkénti migrálás helyett írja le a kívánt átalakítást természetes nyelven, és a modernizálási ügynökök kezelik az elemzést, a tervezést és a kódgenerálást.

Az újraarchitektúra gyakori forgatókönyvei a következők:

  • Struts átváltás Spring MVC-re
  • Strutstól a Spring Bootig
  • JSP a Thymeleafnek
  • EJB–Spring Boot
  • WebSphere-alkalmazások a Spring Bootba
  • Örökölt servlet-alapú alkalmazások a modern spring-alapú architektúrákhoz
  • Windows Forms (WinForms) asztali alkalmazásokat az Angular-webalkalmazásokhoz
  • előtéralkalmazások ASP.NET, MVC Angular-webalkalmazásokhoz

Előfeltételek

  • Visual Studio Code a GitHub Copilot modernizációját segítő bővítménnyel telepítve.
  • Egy GitHub Copilot előfizetés. További információ: Copilot tervek.
  • (Nem kötelező) Python 3.7-es vagy újabb verzió egy tudásgráf létrehozásához, amely az újraírási folyamat során a projekt struktúrájának egyértelműbb megértését teszi lehetővé az ügynök számára. Ha Python nem érhető el, a tudásgráf lépését kihagyja a program.
  • (Nem kötelező) Node.js 18-as vagy újabb verziójú playwright-tesztek futásidejű ellenőrzés részeként történő futtatásához. Ha a Node.js nem érhető el, a Playwright tesztlépés ki lesz hagyva.
  • (Nem kötelező) Docker Desktop futásidejű ellenőrzéshez. Ha a Docker nem érhető el, a futásidejű ellenőrzési lépés kimarad.

Az újraarchitektúra-ügynök használata

Használja a GitHub Copilot Chat panel modernizálási ügynökét.

Projekt újraépítéséhez kövesse az alábbi lépéseket:

  1. Nyisd meg a projektedet a Visual Studio Code-ban.

  2. Nyissa meg a GitHub Copilot Chat panelt.

  3. Válassza ki a(z) modernize ügynököt az ügynökök listájából.

  4. Írja le a végrehajtani kívánt átalakítást. Például:

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

Az ügynök egy többügynökös csapatot koordinál, amely a következő lépéseket hajtja végre:

  1. Elemzés – Megvizsgálja a meglévő kódbázist, azonosítja a keretrendszer mintáit, függőségeit és modulhatárait.
  2. Tervezés – Strukturált megvalósítási tervet hoz létre rendezett feladatokkal és követelmények nyomon követhetőségével.
  3. Végrehajtás – Kódátalakításokat alkalmaz a terv alapján, minden lépésnél érvényesítési ellenőrzésekkel.

Fontos

Az elemzési és tervezési fázisok befejeződése után az ügynök szünetelteti és kéri a megerősítést, mielőtt elkezdené a kódgenerálást. Ezen a ponton alaposan tekintse át a tervet. Kérheti a terv módosítását, módosíthatja a prioritásokat, vagy korlátozásokat adhat hozzá, mielőtt az ügynök folytatná a végrehajtást.

További kontextus biztosítása

Az átalakítási eredményeket úgy javíthatja, ha további kontextust ad meg az üzenetben:

  • Adja meg a cél-keretrendszer verzióit, például : "A Spring Boot 3.2 és Java 21 használata".
  • Dokumentációs hivatkozások vagy migrálási útmutatók.
  • A szervezetspecifikus minták vagy konvenciók leírása.
  • Adja meg, hogy mely modulokat vagy csomagokat kell rangsorolni.

Például:

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.

Gyakori problémák megoldása

Az újraarchitektúra során az ügynök összetevőket hoz létre a .github/modernize/ projekt könyvtárában. Ezeket az összetevőket használva diagnosztizálhatja a felmerülő problémákat.

Létrehozott artifaktumok áttekintése

A .github/modernize/rearchitecture könyvtár a következő fő erőforrásokat tartalmazza:

  • board.md - A feladattábla, amely nyomon követi az összes fázist és annak állapotát. Ellenőrizze a fájlban, hogy a tevékenységek közül melyek mentek át, melyek sikertelenek, vagy szükséges-e iteráció.
  • artifacts/ – Részletes jelentések az egyes tevékenységekről. A fájlok elnevezési konvenciót követnek, például t21-tester-report.md a kezdeti tesztjelentéshez vagy t21.2-tester-report.md az újrapróbálkozási iterációhoz.
  • learn.md - Az egyes szerepkörök által a feladat végrehajtása során naplózott felfedezések, hibamegállapítások és technikák összesített tudásbázisa. Ebben a fájlban megtekintheti az ügynök által észlelt problémákat és azok megoldásának módját.
  • team/ - Szerepkörspecifikus charták, amelyek meghatározzák az egyes ügynökök feladatait.

Ha egy minőségi kapu meghibásodik, az ügynök iterációs összetevőket hoz létre (például t21.1, t21.2), amelyek dokumentálják a javítási kísérleteket. Ezeket a számozott iterációkat a probléma észlelésének és megoldásának megértéséhez keresse meg.

Az elemzés és a terv áttekintése

Mielőtt az ügynök elkezdené írni a kódot, elemzési és tervezési összetevőket hoz létre, amelyeket felül kell vizsgálnia. Ezek az artefaktumok betekintést nyújtanak abba, hogy az ügynök mit értett a projektről, és hogy mit kíván létrehozni.

Az elemzési összetevők a következők:

  • Architektúra összefoglalása: A meglévő technológiai verem, projektstruktúra, adatmodell és integrációs pontok áttekintése. Ellenőrizze ezt az összegzést, hogy az ügynök helyesen azonosította-e a projekt fő összetevőit. Keresse meg az olyan fájlokat, mint a artifacts/t2-architect-architecture-summary.md, artifacts/t2-architect-tech-stack.mdés artifacts/t2-architect-data-model.md.
  • Szolgáltatásleltár: Az eredeti alkalmazás összes funkciójának katalógusa, amelyek mindegyike hozzárendelt egy követelményazonosítót (például REQ-001). Ellenőrizze, hogy a lista teljes és pontos-e. Keresse artifacts/t3-pm-spec.md.
  • Célarchitektúra-tervezés: Az új alkalmazáshoz javasolt API-szerződések, modulstruktúra és technológiai lehetőségek. Keresse meg a fájlokat, például artifacts/t5-architect-api-contracts.md és artifacts/t5-architect-integration.md.

A tervezési összetevők a következők:

  • Megvalósítási terv: A függőségekkel rendelkező tevékenységek rendezett listája, fázisok szerint csoportosítva. Minden feladat egy vagy több követelményre utal vissza a funkciójegyzékből. Keresse artifacts/t7-teamlead-plan.md.
  • Tesztelési stratégia: Az egységtesztek, az integrációs tesztek és a végpontok közötti tesztek tervezett megközelítése. Keresse artifacts/t7-teamlead-testing-strategy.md.

Az ügynök szünetet tart ezen artefaktumok létrehozása után, és megvárja a te megerősítésedet. Használja ezt a lehetőséget a következő lehetőségekre:

  • Ellenőrizze, hogy nincsenek-e hiányzó funkciók a készletből.
  • Ellenőrizze, hogy a célarchitektúra megfelel-e az elvárásainak.
  • A tevékenységprioritások módosítása vagy korlátozások hozzáadása a végrehajtás megkezdése előtt.

Ebben a szakaszban gondos felülvizsgálat segít elkerülni a költséges átdolgozásokat a megvalósítási és ellenőrzési fázisokban.

Buildelési és indítási hibák

Ha az átalakított alkalmazás fordítása vagy elindítása sikertelen, használja a következő megközelítést:

  1. Ellenőrizze a tesztjelentés elemét (például t21-tester-report.md) a build eredménye és a veremlenyomat szempontjából.
  2. Keresse meg a kivétel típusát vagy hibaüzenetét az összetevőben a kiváltó ok azonosításához.
  3. Ha az ügynök javító iterációkat hozott létre (például t21.1, t21.3), tekintse át ezeket az eredményeket, hogy megtudja, milyen módosításokat kíséreltek meg.

Gyakori kiváltó okok a régi és az újonnan létrehozott osztályok közötti elnevezési ütközések, a helytelen Spring-profilkonfigurációk, valamint a pom.xmlhiányzó vagy ütköző függőségek. Ha például a régi és a modern vezérlők ugyanazzal az osztálynévvel osztoznak, a Spring indításkor hibát generál a(z) ConflictingBeanDefinitionException-t.

Futtatókörnyezeti hibák

Ha az alkalmazás elindul, de az API-hívások hibát adnak vissza (például 500 vagy 400 válasz), használja a következő megközelítést:

  1. Ellenőrizze a tesztjelentés azon elemeit, amelyeknél a végpontok nem működtek, valamint a kapcsolódó hibaüzeneteket.
  2. Konfigurációs problémák esetén tekintse át a biztonsági megállapítások összetevőt (például t20-security-findings.md).
  3. Vizsgálja meg a létrehozott entitásosztályokat és a vezérlőkódot az adatbázisséma és az ORM-leképezések közötti eltérésekkel.

A gyakori kiváltó okok közé tartoznak az adatbázis által fenntartott kulcsszóütközések @Column a széljegyzetekben, a DTO-mezőtípusok és az entitásmezőtípusok közötti eltérések, valamint a kérelemobjektumok hiányzó érvényesítési megjegyzései.

Minőségellenőrzési kapuhibák és iterációk

Az ügynök számos minőségi kaput kényszerít ki az újraépítési folyamat során. Ha egy kapu meghibásodik, az ügynök automatikusan létrehozza a kijavított feladatokat, és újrapróbálkozza az ellenőrzést. Gyakori kapuhibák a következők:

  • Architektúra áttekintése: Az ügynök ellenőrzi, hogy az implementáció megfelel-e a tervezett API-szerződéseknek, DTO-struktúráknak és végpontleképezéseknek. A hibák általában hiányzó végpontokat, átnevezett mezőket vagy hiányzó érvényesítési megjegyzéseket tartalmaznak. Adott megállapításokért tekintse át az építészjelentés összetevőt (például t19-architect-review.md).
  • Megfelelőség áttekintése: Az ügynök ellenőrzi, hogy a végrehajtás megfelel-e az eredeti alkotmányban meghatározott összes alapelvnek. Gyakori hiba, hogy hiányoznak a böngészőszintű, végpontok közötti tesztek, amikor az alkotmány megköveteli őket. Tekintse át a csapatvezető áttekintési dokumentumát (például t22-teamlead-review.md) annak megállapításához, hogy mely alapelvek nem teljesültek.
  • Funkció-paritás megerősítése: Az ügynök ellenőrzi, hogy az összes katalógusba vett követelmény teljesült-e. A részleges jóváhagyás azt jelenti, hogy bizonyos funkciók hiányosak, például hiányzik a mezők közötti ellenőrzés, mint például annak biztosítása, hogy fromDate megelőzze toDate-et. Tekintse át a PM bejelentkezési összetevőt (például t23-pm-signoff.md) a követelmény szerinti lebontáshoz.

Ha az ügynök az összes probléma megoldása nélkül eléri az iterációs korlátot, tekintse át a legújabb összetevőfájlokat a fennmaradó rések megértéséhez és manuális javítások alkalmazásához.

Futásidejű érvényesítési előfeltételek

Az ügynök külső eszközöktől függő opcionális futásidejű ellenőrzési lépéseket hajt végre. Ha egy eszköz nem érhető el, a megfelelő lépés kihagyva:

  • Python nincs telepítve: A tudásgráf lépés kihagyva. Az ügynök továbbra is végrehajthatja az újraarchitektúrát, de előfordulhat, hogy kevesebb kontextusa van a projektstruktúrával kapcsolatban. Telepítse a Python 3.7-et vagy újabb verziót, és győződjön meg arról, hogy python3 elérhető a PATH-ban.
  • Node.js nincs telepítve: a playwright böngészőszintű, végpontok közötti tesztek kimaradnak. Az ügynök továbbra is integrációs teszteket futtat a Mavenen keresztül. Telepítse Node.js 18-at vagy újabb verziót a böngésző tesztelésének engedélyezéséhez.
  • A Docker nem érhető el: A futtatókörnyezet ellenőrzése (az alkalmazás tárolóban való indítása és a kérések kiszolgálásának ellenőrzése) kihagyva. Az ügynök ehelyett egység- és integrációs tesztekre támaszkodik. A lépés engedélyezéséhez telepítse és indítsa el a Docker Desktopot.

Korlátozások

Tartsa szem előtt a következő korlátozásokat:

  • A mélyen összekapcsolt örökölt keretrendszerekkel rendelkező összetett projektek több iterációt igényelhetnek.
  • A módosítások véglegesítése előtt gondosan tekintse át a létrehozott kódot.

Visszajelzés küldése

Ha visszajelzést szeretne küldeni az újraarchitektúra funkcióról, hozzon létre egy hibajegyet a github-copilot-appmod adattárban, vagy használja a GitHub Copilot modernizációs visszajelzési űrlapot.

Lásd még

A GitHub Copilot Java-korszerűsítésének áttekintése

  • Utolsó frissítés időpontja: