Rekomendasi untuk memigrasikan aplikasi web lama ke kerangka kerja modern

Saat ini saya sedang melakukan beberapa pekerjaan untuk perusahaan yang menjalankan aplikasi web lama yang dibangun di atas Java Servlets (sistemnya sudah ada sebelum JSP, meskipun mereka sekarang menggunakannya saat membuat halaman baru). Basis kodenya berantakan karena dibangun selama sekitar 10 tahun di atas kerangka kerja yang ketinggalan jaman. Mereka memiliki sangat sedikit konsistensi dalam basis kode (aplikasi telah dikembangkan oleh berbagai orang selama bertahun-tahun, sebagian besar tidak lagi berfungsi di sini), tidak ada konsep KERING (setiap halaman pada dasarnya dibuat dari awal) banyak yang tidak dapat dibaca / samar kode dan secara umum infrastruktur yang sangat tidak konsisten.

Saat saya bekerja di sini, saya telah menambahkan fitur-fitur modern/mencoba membersihkan basis kode sedikit. Saya menambahkan beberapa jQuery ke tempat saya terpapar, memperkenalkan sedikit keamanan dengan validasi input, membersihkan beberapa modul untuk menggunakan prinsip JavaScript yang tidak mengganggu, dll. Pekerjaan saya di sini adalah pada modul baru jadi saya tidak banyak terpapar pada modul lama logika. Saya telah mencoba memperkenalkan praktik terbaik untuk semua pekerjaan saya di bawah infrastruktur mereka saat ini, tetapi saya terpaksa memanggil banyak kode lama mereka untuk membuat pekerjaan saya konsisten.

Mereka telah mencapai titik di mana mereka sekarang mempertimbangkan pembaruan besar-besaran pada sistem. Mereka ingin meningkatkan pemeliharaan basis kode dan mencoba untuk pindah ke semacam kerangka kerja modern/aplikasi tipe MVC. Banyak sistem mendahului XHTML dengan markup gaya sebaris, panggilan javascript:function(), tanpa pengujian unit, sebelum Hibernate, dll. Ada campuran pembuatan html out.println dan pemanggilan jsp dari dalam Servlet.

Beberapa aplikasi yang mereka lihat termasuk Wicket, Struts, Tapestry, dan mungkin Grails. Permasalahannya adalah, perpindahan ke salah satu dari sistem ini mungkin memerlukan penulisan ulang besar-besaran terhadap sistem yang sudah digunakan dan mereka tidak mampu untuk memulai kembali.

Pertanyaan saya adalah: Apa cara terbaik untuk memigrasikan basis kode lama seperti ini ke kerangka kerja yang lebih modern sambil tetap menjaga logika bisnis yang ada (tidak ada gunanya menulis ulang hal-hal yang telah diuji dan berfungsi).

Beberapa ide yang sedang dipikirkan antara lain:

  • tulis sistem templating internal yang akan berfungsi dengan infrastruktur mereka saat ini (hasilkan halaman dengan cara yang konsisten)

  • kode port ke kerangka kerja seperti permadani (menggunakan kembali banyak kode lamanya)

  • menulis ulang sistem dari awal menggunakan kerangka kerja modern tetapi menyalin logika dari sistem lama (jika memungkinkan)

  • pertahankan sistem lama apa adanya dan cukup perbarui halaman depan untuk memberikan tampilan yang lebih modern (mungkin lebih baik jika diberikan waktu/uang, dll.)

apa cara terbaik untuk memperbarui kode Java Servlet lama ke kerangka kerja modern (menggunakan praktik modern untuk memudahkan pemeliharaan, pengujian unit, KERING) sambil menjaga logika tetap utuh?

wawasan apa pun diterima.


person kgrad    schedule 20.02.2009    source sumber


Jawaban (5)


Lakukan pemfaktoran ulang, upayakan menuju gaya desain yang konsisten, sebagai permulaan untuk memindahkannya ke kerangka yang paling dekat dengan semangat apa pun gaya tersebut nantinya.

Yang saya maksud dengan "refactor" - memperkenalkan tes di lokasi strategis, unit maupun fungsional, dan bekerja keras untuk mengurangi duplikasi, bersandar pada tes ini.

person Morendil    schedule 20.02.2009

Saya menanyakan pertanyaan serupa beberapa bulan lalu, beberapa jawabannya mungkin berguna bagi Anda:

Apa yang terbaik bagaimana cara memigrasikan aplikasi web berantakan yang ada ke MVC yang elegan?

person matt b    schedule 20.02.2009

Tidak ada jawaban yang jelas untuk pertanyaan semacam ini, namun tip utama saya adalah membaca subjeknya terlebih dahulu. Bacalah buku karya orang-orang yang mengetahui hal-hal yang mereka bicarakan.

Misalnya, Code Complete (Steve McConnell), ch. 24 Pemfaktoran ulang.

  • Simpan kode yang Anda gunakan untuk memulai

  • Pertahankan pemfaktoran ulang dalam jumlah kecil

  • Lakukan pemfaktoran ulang satu per satu

  • Refactor ketika Anda menambahkan rutinitas, kelas, memperbaiki kerusakan

  • Tentukan antarmuka antara kode bersih dan kode jelek

  • ...

Ada banyak sumber lain, baik cetak maupun online, yang dapat Anda gunakan. Setelahnya, jika Anda memiliki pertanyaan yang lebih spesifik, Anda dapat menggunakan situs seperti SO untuk mendapatkan jawaban yang lebih bermanfaat daripada ini.

person eljenso    schedule 20.02.2009

Cara terbaik: Gunakan aplikasi yang ada sebagai spesifikasi fungsional dan buat aplikasi baru dari awal (dengan beberapa kemungkinan penggunaan kembali potong-dan-tempel atau penggunaan kembali kelas aktual jika memungkinkan).

Dari pengalaman saya, mencoba memasukkan aplikasi lama yang ditulis dengan buruk ke dalam kerangka kerja baru atau mencoba "membungkus" kode sampah dengan kode yang baik hanya akan menghasilkan sesuatu yang lebih sulit dan mahal untuk dipertahankan dalam jangka panjang.

person Eric Petroelje    schedule 20.02.2009

ini hanya pendapat saya, karena menurut saya pertanyaan ini adalah pertanyaan tentang apa yang harus dilakukan orang untuk membayar konsultan mahal (dan biasanya hanya membuang-buang uang! lihat thedailywtf.com sebagai contoh).

Menurut saya ini tidak layak untuk ditulis ulang sepenuhnya, karena selama proses penulisan ulang, Anda mungkin juga harus mempertahankan aplikasi asli*, sehingga penulisan ulang akan memiliki target yang bergerak. cara yang lebih baik adalah dengan melunasi hutang kode saat Anda melakukan refaktorisasi - yaitu, diperlukan upaya 2x, 3x, atau bahkan 10x untuk mengimplementasikan satu fitur sederhana, hanya karena melakukannya dengan cara yang baik melibatkan pemfaktoran ulang tumpukan. Namun upaya ini diperlukan, karena utang dalam aplikasi ini tinggi, dan akhirnya harus dibayar entah bagaimana caranya.

mungkin menyakitkan, tapi obat yang baik itu menyakitkan.

  • jika Anda diberi banyak waktu untuk melakukan penulisan ulang, yaitu, aplikasi asli dibekukan dan tidak dikelola (bahkan tidak ada perbaikan bug), maka ini mungkin berfungsi sebagai penulisan ulang lengkap ke dalam kerangka apa pun yang Anda anggap cocok. tapi saya sangat ragu hal ini akan terjadi di institusi mana pun.
person Chii    schedule 21.02.2009