Modernisasi kode lama membutuhkan arkeologi terlebih dahulu

Hal tersulit tentang kode lama bukanlah sintaksis lama, melainkan masa lalu. Sebuah proyek diisi dengan build.xml, JDK lama, kerangka pengujian lama, dan metode pengemasan lama. Di permukaan, tampak seperti beberapa tumpukan file, namun sebenarnya itu adalah lapisan asumsi sejarah yang bertumpuk satu sama lain. Kodenya sendiri hanya lapisan terluar saja. Apa yang sebenarnya menghambat penyampaian sering kali adalah apakah asumsi-asumsi tersebut masih ada, apakah asumsi-asumsi tersebut dapat direproduksi, dan apakah perilaku lama akan hilang setelah adanya perubahan.

Inilah sebabnya mengapa “arkeologi” mendahului “transformasi”. Lihat file build terlebih dahulu, lalu dependensinya, lalu lingkungan yang berjalan, lalu pengujiannya. Urutannya tidak dapat dibatalkan. Build.xml masih ada, tetapi pom.xml tidak ada. Sinyal seperti itu cukup untuk menunjukkan bahwa proyek tersebut berada di era Ant; apakah kode dapat dikompilasi, apakah pengujian dapat dijalankan, dan apakah produk dapat dibuat ulang adalah bukti pertama. Bagian paling berguna dari model di sini bukanlah untuk segera menulis kode baru untuk kode lama, namun untuk mengidentifikasi bukti-bukti ini dari tumpukan fragmen.

Lingkungan juga harus diprioritaskan terlebih dahulu. Kode lama sering kali disertai dengan JVM lama, container lama, dan asumsi arsitektur lama. Melemparkannya langsung ke mesin saat ini, terutama di lingkungan lintas-arsitektur, dan mudah untuk mencampurkan kebisingan baru ketika masalah terjadi: apakah kode secara inheren rusak, atau apakah emulasi, pencerminan, dan rantai alat yang menyebabkan masalah? Jika Anda bahkan tidak dapat mencapai “kode yang sama dapat direproduksi secara stabil di lingkungan yang sama” pada tahap ini, semua tindakan modernisasi berikutnya hanya berupa dugaan.

Nilai AI dalam langkah ini jelas: dapat membantu penerjemahan tingkat karakter dan tingkat struktur. Mengonversi Ant ke Gradle, mengonversi skrip build lama menjadi bentuk yang sekarang dapat dikelola, memindahkan sekumpulan XML berulang dan boilerplate ke lokasi yang lebih jelas adalah kandidat yang baik untuk diserahkan ke model. Cepat, mau mencoba lagi dan lagi, dan tidak terlalu sepele. Tapi itu tidak cocok untuk wasit. Peringatan mana yang dapat dipertahankan terlebih dahulu, pengujian mana yang sebenarnya berbohong, modul mana yang harus dihentikan terlebih dahulu, dan kelas mana yang sebaiknya hanya dikemas dan diadaptasi. Pada akhirnya tetap harus diputuskan oleh masyarakat.

Pengujian adalah cara termudah untuk membodohi orang. Lulus pengujian di proyek lama tidak berarti bahwa sistemnya dipahami, ini mungkin hanya berarti bahwa beberapa perilaku lama hanya dimasukkan ke dalam lingkungan saat ini. Perasaan “hijau” itu berbahaya karena sering kali menutupi masalah yang lebih besar: yang diverifikasi oleh tes tersebut adalah detail implementasi pada era tertentu, bukan semantik bisnis yang perlu dilestarikan saat ini. Jika Anda benar-benar ingin melakukan reformasi, hal pertama yang harus dilakukan adalah mengambil ujian ini dari “rasa aman dekoratif” dan menilai kembali apa yang mereka lindungi.

Oleh karena itu, cara paling stabil untuk proyek jenis ini biasanya adalah dengan tidak menulis ulang sekaligus, tetapi terlebih dahulu membuat kapsul waktu untuk memperbaiki lingkungan lama, perilaku lama, dan ketergantungan lama, lalu menghapusnya di sepanjang celah yang paling sempit. Pertama-tama buatlah sistem tersebut dapat direproduksi, lalu serahkan pekerjaan berulang tersebut kepada AI untuk diterjemahkan, lalu kupas batasannya lapis demi lapis. Jika urutannya tidak sesuai, model tersebut akan mempercepat proyek lama dan mendorongnya ke dalam kekacauan yang lebih dalam; jika urutannya benar, model tersebut akan menjadi seperti asisten arkeologi yang sangat berguna, bertanggung jawab untuk memindahkan batu bata, membersihkan debu, dan membandingkan bukti, membebaskan orang dari pekerjaan kotor dan menyerahkan penilaian di tangan mereka.