GitHub Copilot modernleştirme kullanarak projeleri yeniden tasarlayın

Bu makalede, struts ile Spring MVC gibi eski çerçevelerden modern mimarilere projeleri yeniden yazmak için GitHub Copilot modernleştirmede yeniden mimari özelliğinin nasıl kullanılacağı açıklanmaktadır.

Genel bakış

Yeniden mimari özelliği, yapay zeka destekli çok aracılı bir iş akışı kullanarak projenin tamamını eski bir çerçeveden modern bir mimariye dönüştürmenizi sağlar. El ile dosyaya geçiş yerine doğal dilde istenen dönüşümü açıklar ve modernleştirme aracıları analiz, planlama ve kod oluşturmayı işler.

Yaygın yeniden mimari senaryoları şunlardır:

• Struts'tan Spring MVC'ye Geçiş
• Struts'tan Spring Boot'a
• JSP'den Thymeleaf'e Geçiş
• EJB'yi Spring Boot'a
• Spring Boot'a WebSphere uygulamaları
• Modern Spring tabanlı mimarilere eski servlet tabanlı uygulamalar
• Angular web uygulamalarına Windows Forms (WinForms) masaüstü uygulamaları
• ASP.NET MVC ön uç uygulamalarından Angular web uygulamalarına

Önkoşullar

• GitHub Copilot modernleştirme uzantısının yüklü olduğu Visual Studio Code.
• GitHub Copilot aboneliği. Daha fazla bilgi için bkz. Copilot plans.
• (İsteğe bağlı) bir bilgi grafiği oluşturmak için Python 3.7 veya sonraki bir sürümü, aracıya yeniden yazma işlemi sırasında proje yapınızı daha net bir şekilde anlama olanağı sağlar. Python kullanılamıyorsa bilgi grafiği adımı atlanır.
• (İsteğe bağlı) Node.js 18 veya daha sonraki bir sürümü, çalışma zamanı doğrulamasının bir parçası olarak Playwright testlerini çalıştırmak için. Node.js kullanılamıyorsa Playwright test adımı atlanır.
• (İsteğe bağlı) Çalışma zamanı doğrulaması için Docker Desktop . Docker kullanılamıyorsa çalışma zamanı doğrulama adımı atlanır.

Yeniden yapılandırma aracını kullanın

GitHub Copilot Chat panelindeki modernleştirme aracısını kullanın.

Bir projenin yeniden mimarisini oluşturmak için aşağıdaki adımları kullanın:

1. Projenizi Visual Studio Code açın.

2. GitHub Copilot Chat panelini açın.

3. Aracı listesinde modernize aracısını seçin.

4. Gerçekleştirmek istediğiniz dönüşümü açıklayın. Örneğin:

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

Aracı, aşağıdaki adımları gerçekleştiren çok aracılı bir ekibi koordine eder:

1. Analiz - Çerçeve desenlerini, bağımlılıklarını ve modül sınırlarını tanımlayarak mevcut kod tabanını inceler.
2. Planlama - Sıralı görevler ve gereksinim izlenebilirliği ile yapılandırılmış bir uygulama planı oluşturur.
3. Yürütme - Planı izleyen kod dönüşümlerini uygular ve her adımda doğrulama denetimleri yapar.

Önemli

Analiz ve planlama aşamaları tamamlandıktan sonra, ajan duraklar ve kod oluşturma işlemine başlamadan önce onayınızı ister. Bu noktada planı dikkatlice gözden geçirin. Aracı uygulamaya geçmeden önce planda değişiklik isteyebilir, öncelikleri ayarlayabilir veya kısıtlamalar ekleyebilirsiniz.

Daha fazla bağlam sağlayın

İsteminizde ek bağlam sağlayarak dönüştürme sonuçlarını geliştirebilirsiniz:

• Hedef çerçeve sürümlerini belirtin; örneğin, "Spring Boot 3.2 ve Java 21'i kullanın."
• Başvuru belgeleri bağlantıları veya geçiş kılavuzları.
• Kuruluşa özgü desenleri veya kuralları açıklama.
• Hangi modüllerin veya paketlerin önceliklerinin belirlendiğini belirtin.

Örneğin:

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.

Yaygın sorunları giderme

Yeniden mimari işlemi sırasında, aracı projenizin .github/modernize/ dizininde eserler oluşturur. Ortaya çıkan sorunları tanılamak için bu yapıtları kullanın.

Oluşturulan artefaktları gözden geçirme

.github/modernize/rearchitecture Dizin aşağıdaki temel kaynakları içerir:

• board.md - Her aşamayı ve durumunu izleyen görev panosu. Hangi görevlerin geçtiğini, başarısız olduğunu veya gerekli yinelemeleri görmek için bu dosyayı denetleyin.
• artifacts/ - Her görevden ayrıntılı raporlar. Dosyalar, t21-tester-report.md gibi bir ilk test raporu veya t21.2-tester-report.md gibi bir yeniden deneme yinelemesi için bir adlandırma kuralına uyar.
• learn.md - Görev yürütme sırasında her rol tarafından günlüğe kaydedilen keşifler, hata bulguları ve tekniklerin kümülatif bilgi bankası. Aracın karşılaştığı sorunlara ve bunların nasıl çözüldüğüne dair içgörüler için bu dosyayı kontrol edin.
• team/ - Her bir temsilcinin sorumluluklarını tanımlayan role özgü çerçeveler.

Kalite kapısı başarısız olduğunda aracı, düzeltme girişimlerini belgeleyen yineleme yapıtları (örneğin, t21.1, t21.2) oluşturur. Sorunun nasıl algılandığını ve çözüldüğünü anlamak için bu numaralandırılmış yinelemeleri arayın.

Analizi ve planı gözden geçirin

Kod yazmaya başlamadan önce, aracı incelemeniz gereken analiz ve planlama dökümanları oluşturur. Bu eserler, aracının projeniz hakkında neleri anladığını ve ne inşa etmeyi planladığını size görünürlük sağlar.

Analiz belgeleri şunlardır:

• Mimari özeti: Mevcut teknoloji yığınına, proje yapısına, veri modeline ve tümleştirme noktalarına genel bakış. Aracının projenizin temel bileşenlerini doğru şekilde tanımladığını doğrulamak için bu özete bakın. , artifacts/t2-architect-architecture-summary.mdve artifacts/t2-architect-tech-stack.mdgibi artifacts/t2-architect-data-model.mddosyaları arayın.
• Özellik envanteri: Her birine bir gereksinim kimliği atanmış özgün uygulamadaki tüm özelliklerin kataloğu (örneğin, REQ-001). Bu listenin eksiksiz ve doğru olduğunu doğrulayın. öğesini arayın artifacts/t3-pm-spec.md.
• Hedef mimari tasarımı: Yeni uygulama için önerilen API sözleşmeleri, modül yapısı ve teknoloji seçenekleri. ve artifacts/t5-architect-api-contracts.mdgibi artifacts/t5-architect-integration.md dosyaları arayın.

Planlama yapıtları şunlardır:

• Uygulama planı: Aşamalar halinde gruplandırılmış, bağımlılıkları olan sıralı bir görev listesi. Her görev, özellik envanterinden bir veya daha fazla gereksinime geri eşler. öğesini arayın artifacts/t7-teamlead-plan.md.
• Test stratejisi: Birim testleri, tümleştirme testleri ve uçtan uca testler için planlanan yaklaşım. öğesini arayın artifacts/t7-teamlead-testing-strategy.md.

Aracı, bu artifaktları ürettikten sonra duraklar ve onayınızı bekler. Bu fırsatı kullanarak:

• Envanterde eksik özellik olmadığını doğrulayın.
• Hedef mimarinin beklentilerinizle eşleştiğinden emin olun.
• Uygulama başlamadan önce görev önceliklerini ayarlayın veya kısıtlamalar ekleyin.

Bu aşamada dikkatli bir inceleme, uygulama ve doğrulama aşamaları sırasında yüksek maliyetli yeniden çalışmalardan kaçınmaya yardımcı olur.

Derleme ve başlatma hataları

Dönüştürülen uygulama derlenemez veya başlatılamazsa aşağıdaki yaklaşımı kullanın:

1. Derleme çıktısı ve yığın izlemeleri için test raporu artifaktını (örneğin, t21-tester-report.md) kontrol edin.
2. Kök nedeni tanımlamak için yapıtta özel durum türünü veya hata iletisini arayın.
3. Aracı düzeltme yinelemeleri oluşturduysa (örneğin t21.1, t21.3), hangi değişikliklerin denendiğini görmek için bu yapıtları gözden geçirin.

Yaygın kök nedenler arasında eski ve yeni oluşturulan sınıflar arasındaki adlandırma çakışmaları, hatalı Spring profili yapılandırmaları ve içinde pom.xmleksik veya çakışan bağımlılıklar bulunur. Örneğin, eski ve modern denetleyiciler aynı sınıf adını paylaşıyorsa Spring başlangıçta bir ConflictingBeanDefinitionException oluşturur.

Çalışma zamanı hataları

Uygulama başlatılır ancak API çağrıları hata döndürürse (500 veya 400 yanıt gibi), aşağıdaki yaklaşımı kullanın:

1. Uç noktaların başarısız olduğu test raporu yapıtını ve ilişkili hata iletilerini kontrol edin.
2. Yapılandırma sorunları için güvenlik bulguları yapıtını (örneğin, t20-security-findings.md) gözden geçirin.
3. Oluşturulan varlık sınıflarını ve denetleyici kodunu veritabanı şeması ile ORM eşlemeleri arasındaki uyuşmazlıkları inceleyin.

Yaygın kök nedenler arasında @Column notlarındaki veritabanı ayrılmış anahtar kelime çakışmaları, DTO saha türleri ile varlık saha türleri arasındaki uyuşmazlıklar ve istek nesnelerinde eksik doğrulama notları bulunur.

Kalite kontrol noktası hataları ve yinelemeleri

Aracı, yeniden mimari işlemi sırasında çeşitli kalite geçitleri uygular. Bir geçit başarısız olduğunda ajan otomatik olarak düzeltme görevleri oluşturur ve doğrulamayı yeniden dener. Yaygın geçit hataları şunlardır:

• Mimari gözden geçirmesi: Aracı, uygulamanın tasarlanan API sözleşmeleri, DTO yapıları ve uç nokta eşlemeleriyle eşleşip eşleşmediğini denetler. Hatalar genellikle eksik uç noktaları, yeniden adlandırılan alanları veya eksik doğrulama ek açıklamalarını içerir. Belirli bulgular için mimar raporu belgesini (örneğin, t19-architect-review.md) gözden geçirin.
• Uyumluluk gözden geçirmesi: Aracı, uygulamanın ilk anayasada tanımlanan tüm ilkeleri karşıladığını doğrular. Yaygın bir hata, anayasa gerektirdiğinde tarayıcı düzeyinde uçtan uca testlerin eksik olmasıdır. Hangi ilkelerin karşılanmamış olduğunu belirlemek için ekip lideri gözden geçirme yapıtını (örneğin, t22-teamlead-review.md) gözden geçirin.
• Özellik eşdeğerliği onayı: Yetkili, tüm kataloglanmış gereksinimlerin uygulandığını doğrular. Kısmi onay, belirli özelliklerin eksik olduğu anlamına gelir; örneğin, alanlar arası doğrulama eksikliği, fromDate'in toDate'den önce olduğunu doğrulamak gibi. PM onay yapıtını (örneğin, t23-pm-signoff.md) gereksinimlere göre döküm için gözden geçirin.

Ajan tüm sorunları çözmeden tekrarlama sınırına ulaşıyorsa, kalan boşlukları anlamak ve manuel düzeltmeler uygulamak için en son yapıt dosyalarını gözden geçirin.

Çalışma zamanı doğrulama önkoşulları

Aracı, dış araçlara bağlı olan isteğe bağlı doğrulama adımlarını çalışma esnasında gerçekleştirir. Araç kullanılamıyorsa ilgili adım atlanır:

• Python yüklü değil: Bilgi grafiği adımı atlanır. Etmen, yeniden yapılandırmayı gerçekleştirmeye devam edebilir, ancak proje yapınız hakkında daha az bilgiye sahip olabilir. Python 3.7 veya üzerini yükleyin ve PATH'inizde python3 kullanılabilir olduğundan emin olun.
• Node.js yüklü değil: Playwright tarayıcı düzeyinde uçtan uca testler atlanır. Aracı, hala Maven aracılığıyla tümleştirme testlerini çalıştırmaktadır. Tarayıcı testlerini etkinleştirmek için Node.js 18 veya üzerini yükleyin.
• Docker kullanılamıyor: Çalışma zamanı doğrulaması (uygulamayı bir kapsayıcıda başlatma ve isteklere hizmet ediyor olduğunu doğrulama) atlanır. Bunun yerine, aracı birim ve tümleştirme testlerine dayanır. Bu adımı etkinleştirmek için Docker Desktop'ı yükleyin ve başlatın.

Sınırlamalar

Aşağıdaki sınırlamaları göz önünde bulundurun:

• Derin bir şekilde bağlanmış eski çerçevelere sahip karmaşık projeler birden çok yineleme gerektirebilir.
• Değişiklikleri işlemeden önce oluşturulan kodu dikkatle gözden geçirmelisiniz.

Geri bildirimde bulunun

Yeniden mimari özelliği hakkında geri bildiriminiz varsa github-copilot-appmod deposunda bir sorun oluşturun veya GitHub Copilot modernleştirme geri bildirim formunu kullanın.

Ayrıca bakınız

Java için GitHub Copilot modernizasyonuna genel bakış