Merancang ulang proyek dengan menggunakan modernisasi GitHub Copilot

Artikel ini menjelaskan cara menggunakan fitur arsitektur ulang dalam modernisasi GitHub Copilot untuk menulis ulang proyek dari kerangka kerja warisan hingga arsitektur modern, seperti dari Struts ke Spring MVC.

Ikhtisar

Fitur arsitektur ulang memungkinkan Anda mengubah seluruh proyek dari kerangka kerja warisan ke arsitektur modern dengan menggunakan alur kerja multi-agen yang didukung AI. Alih-alih migrasi file demi file manual, jelaskan transformasi yang diinginkan dalam bahasa alami, dan agen modernisasi menangani analisis, perencanaan, dan pembuatan kode.

Skenario arsitektur ulang umum meliputi:

• Struts ke Spring MVC
• Dari Struts ke Spring Boot
• JSP ke Thymeleaf
• EJB ke Spring Boot
• Aplikasi WebSphere untuk Spring Boot
• Aplikasi berbasis servlet warisan untuk arsitektur modern berbasis Spring
• aplikasi desktop Formulir Windows (WinForms) menjadi aplikasi web Angular
• Aplikasi front-end ASP.NET MVC ke aplikasi web Angular

Prasyarat

• Visual Studio Code dengan ekstensi modernisasi GitHub Copilot terinstal.
• Langganan untuk GitHub Copilot. Untuk informasi selengkapnya, lihat rencana Copilot.
• (Opsional) Python 3.7 atau yang lebih baru untuk membangun grafik pengetahuan, yang memberi agen pemahaman yang lebih jelas tentang struktur proyek Anda selama proses penulisan ulang. Jika Python tidak tersedia, langkah grafik pengetahuan akan dilewati.
• (Opsional) Node.js 18 atau yang lebih baru untuk menjalankan pengujian Playwright sebagai bagian dari validasi runtime. Jika Node.js tidak tersedia, langkah pengujian Playwright akan dilewati.
• (Opsional) Docker Desktop untuk validasi runtime. Jika Docker tidak tersedia, langkah validasi runtime akan dilewati.

Gunakan agen rekayasa ulang

Gunakan agen modernisasi di panel gitHub Copilot Chat.

Gunakan langkah-langkah berikut untuk merancang ulang proyek:

1. Buka proyek Anda di Visual Studio Code.

2. Buka panel GitHub Copilot Chat.

3. Pilih agen modernize dari daftar agen.

4. Jelaskan transformasi yang ingin Anda lakukan. Contohnya:

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

Agen mengoordinasikan tim multi-agen yang melakukan langkah-langkah berikut:

1. Analisis - Memeriksa basis kode yang ada, mengidentifikasi pola kerangka kerja, dependensi, dan batas modul.
2. Perencanaan - Menghasilkan rencana implementasi terstruktur dengan tugas yang diurutkan dan keterlacakan persyaratan.
3. Eksekusi - Menerapkan transformasi kode sesuai rencana, dengan pemeriksaan validasi di setiap langkah.

Berikan konteks lainnya

Anda dapat meningkatkan hasil transformasi dengan memberikan konteks tambahan dalam perintah Anda:

• Tentukan versi kerangka kerja target, misalnya, "Gunakan Spring Boot 3.2 dan Java 21."
• Tautan dokumentasi referensi atau panduan migrasi.
• Menjelaskan pola atau konvensi khusus organisasi.
• Menunjukkan modul atau paket mana yang akan diprioritaskan.

Contohnya:

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.

Pemecahan Masalah Umum

Selama proses arsitektur ulang, agen menghasilkan artefak di .github/modernize/ direktori proyek Anda. Gunakan artefak ini untuk mendiagnosis masalah saat muncul.

Meninjau artefak yang dihasilkan

.github/modernize/rearchitecture Direktori berisi sumber daya utama berikut:

• board.md - Papan tugas yang melacak setiap fase dan statusnya. Periksa file ini untuk melihat tugas mana yang berhasil, gagal, atau yang memerlukan pengulangan.
• artifacts/ - Laporan terperinci dari setiap tugas. File mengikuti konvensi penamaan seperti t21-tester-report.md untuk laporan pengujian awal, atau t21.2-tester-report.md untuk perulangan coba lagi.
• learn.md - Pangkalan pengetahuan kumulatif penemuan, temuan bug, dan teknik yang dicatat oleh setiap peran selama eksekusi tugas. Periksa file ini untuk mendapatkan wawasan tentang masalah yang dihadapi agen dan cara mengatasinya.
• team/ - Piagam khusus peran yang menentukan tanggung jawab setiap agen.

Ketika gerbang kualitas gagal, agen membuat artefak iterasi (misalnya, t21.1, t21.2) yang mendokumentasikan upaya perbaikan. Cari iterasi yang diberi nomor ini untuk memahami bagaimana masalah terdeteksi dan diselesaikan.

Tinjau analisis dan rencana

Sebelum agen mulai menulis kode, ia menghasilkan artefak analisis dan perencanaan yang harus Anda tinjau. Artefak ini memberi Anda visibilitas tentang apa yang dipahami agen tentang proyek Anda dan apa yang ingin dibangunnya.

Artefak analisis meliputi:

• Ringkasan arsitektur: Gambaran umum tumpukan teknologi, struktur proyek, model data, dan titik integrasi yang ada. Periksa ringkasan ini untuk memverifikasi agen yang mengidentifikasi komponen utama proyek Anda dengan benar. Cari file seperti artifacts/t2-architect-architecture-summary.md, artifacts/t2-architect-tech-stack.md, dan artifacts/t2-architect-data-model.md.
• Inventori fitur: Katalog semua fitur dalam aplikasi asli, masing-masing diberi ID persyaratan (misalnya, REQ-001). Verifikasi bahwa daftar ini lengkap dan akurat. Cari artifacts/t3-pm-spec.md.
• Desain arsitektur target: Kontrak API yang diusulkan, struktur modul, dan pilihan teknologi untuk aplikasi baru. Cari file seperti artifacts/t5-architect-api-contracts.md dan artifacts/t5-architect-integration.md.

Artefak perencanaan meliputi:

• Rencana implementasi: Daftar tugas yang diurutkan dengan dependensi, dikelompokkan ke dalam fase. Setiap tugas menghubungkan ke satu atau beberapa persyaratan dari inventori fitur. Cari artifacts/t7-teamlead-plan.md.
• Strategi pengujian: Pendekatan yang direncanakan untuk pengujian unit, pengujian integrasi, dan pengujian end-to-end. Cari artifacts/t7-teamlead-testing-strategy.md.

Agen berhenti sejenak setelah membuat artefak ini dan menunggu konfirmasi Anda. Gunakan kesempatan ini untuk:

• Verifikasi bahwa tidak ada fitur yang hilang dari inventori.
• Periksa apakah arsitektur target sesuai dengan harapan Anda.
• Sesuaikan prioritas tugas atau tambahkan batasan sebelum implementasi dimulai.

Tinjauan yang cermat pada tahap ini membantu menghindari pengerjaan ulang yang mahal selama fase implementasi dan validasi.

Kegagalan dalam proses build dan startup

Jika aplikasi yang diubah gagal dikompilasi atau dimulai, gunakan pendekatan berikut:

1. Periksa artefak laporan penguji (misalnya, t21-tester-report.md) untuk output build dan jejak tumpukan.
2. Cari jenis pengecualian atau pesan kesalahan dalam artefak untuk mengidentifikasi akar penyebabnya.
3. Jika agen membuat iterasi perbaikan (misalnya, t21.1, t21.3), tinjau artefak tersebut untuk melihat perubahan apa yang dicoba.

Akar penyebab umum termasuk tabrakan penamaan antara kelas lama dan yang baru dihasilkan, konfigurasi profil Spring yang salah, dan dependensi yang hilang atau konflik di pom.xml. Misalnya, jika pengontrol warisan dan modern memiliki nama kelas yang sama, Spring melempar ConflictingBeanDefinitionException saat startup.

Kesalahan runtime

Jika aplikasi dimulai tetapi panggilan API mengembalikan kesalahan (seperti respons 500 atau 400), gunakan pendekatan berikut:

1. Periksa artefak laporan penguji untuk melihat endpoint mana yang gagal dan pesan kesalahan terkait.
2. Tinjau artefak temuan keamanan (misalnya, t20-security-findings.md) untuk masalah konfigurasi.
3. Periksa kelas entitas dan kode pengontrol yang dihasilkan untuk ketidakcocokan antara skema database dan pemetaan ORM.

Akar penyebab umum termasuk konflik kata kunci cadangan database dalam @Column anotasi, ketidakcocokan antara jenis bidang DTO dan jenis bidang entitas, serta hilangnya anotasi validasi pada objek permintaan.

Kegagalan dan iterasi gerbang kualitas

Agen memberlakukan beberapa gerbang kualitas selama proses arsitektur ulang. Ketika gerbang gagal, agen secara otomatis membuat tugas perbaikan dan mencoba kembali validasi. Kegagalan gerbang umum meliputi:

• Tinjauan arsitektur: Agen memeriksa bahwa implementasi cocok dengan kontrak API yang dirancang, struktur DTO, dan pemetaan titik akhir. Kegagalan biasanya melibatkan titik akhir yang hilang, bidang yang diganti namanya, atau anotasi validasi yang hilang. Tinjau artefak laporan arsitek (misalnya, t19-architect-review.md) untuk temuan tertentu.
• Tinjauan kesesuaian: Agen memverifikasi bahwa implementasi memenuhi semua prinsip yang ditentukan dalam konstitusi awal. Kegagalan umum adalah tidak adanya pengujian end-to-end pada tingkat browser ketika ketentuan memerlukannya. Tinjau artefak ulasan pemimpin tim (misalnya, t22-teamlead-review.md) untuk mengidentifikasi prinsip mana yang tidak terpenuhi.
• Persetujuan Kesetaraan Fitur: Agen memverifikasi bahwa semua persyaratan yang terdaftar telah diimplementasikan. Sign-off parsial berarti beberapa fitur spesifik tidak lengkap, contohnya validasi lintas bidang yang hilang, seperti memastikan fromDate berada sebelum toDate. Tinjau artefak tanda tangan PM (misalnya, t23-pm-signoff.md) untuk perincian rinci persyaratan berdasarkan persyaratan.

Jika agen mencapai batas iterasinya tanpa menyelesaikan semua masalah, tinjau file artefak terbaru untuk memahami celah yang tersisa dan menerapkan perbaikan manual.

Prasyarat validasi waktu jalan

Agen melakukan langkah-langkah validasi runtime opsional yang bergantung pada alat eksternal. Jika alat yang diperlukan tidak tersedia, langkah yang sesuai akan dilewati.

• Python tidak diinstal: Langkah graf pengetahuan dilewatkan. Agen masih dapat melakukan arsitektur ulang, tetapi mungkin memiliki lebih sedikit konteks tentang struktur proyek Anda. Instal Python 3.7 atau yang lebih baru dan pastikan python3 tersedia di PATH Anda.
• Node.js tidak diinstal: Pengujian menyeluruh tingkat browser Playwright terlewat. Agen masih menjalankan pengujian integrasi melalui Maven. Instal Node.js 18 atau yang lebih baru untuk mengaktifkan pengujian browser.
• Docker tidak tersedia: Validasi runtime (memulai aplikasi dalam kontainer dan memverifikasi bahwa aplikasi melayani permintaan) dilewati. Agen mengandalkan pengujian unit dan integrasi sebagai alternatif. Instal dan mulai Docker Desktop untuk mengaktifkan langkah ini.

Keterbatasan

Ingatlah batasan berikut:

• Proyek kompleks dengan kerangka kerja warisan yang sangat digabungkan mungkin memerlukan beberapa iterasi.
• Anda harus meninjau kode yang dihasilkan dengan hati-hati sebelum melakukan perubahan.

Berikan tanggapan

Jika Anda memiliki umpan balik tentang fitur arsitektur ulang, buat masalah di repositori github-copilot-appmod atau gunakan formulir umpan balik modernisasi GitHub Copilot.

Baca juga

Gambaran umum modernisasi GitHub Copilot untuk Java