Mengambil Alih Sistem Legacy: Stabilkan Dulu, Rewrite (Hampir) Tidak Pernah

Mengambil Alih Sistem Legacy: Stabilkan Dulu, Rewrite (Hampir) Tidak Pernah

Telepon masuk dari klien. Sistemnya masih jalan — pincang, tapi jalan. Orang yang membangunnya sudah tidak ada: pindah kerja, tidak bisa dihubungi, atau memang tidak pernah menulis apa-apa. Dokumentasi tidak ada, test suite tidak ada. Runbook deployment — dokumen langkah-langkah operasional yang tinggal diikuti? Jangan tanya.

Klien seperti ini tidak sedang mencari ceramah soal technical debt. Dia mau sistemnya jalan — dan jalannya minggu depan.

Pekerjaan seperti ini punya nama: rescue engagement. Disiplinnya sendiri, beda dari proyek greenfield yang bangun dari nol, beda juga dari maintenance biasa.

Godaannya — dari klien, kadang dari saya sendiri — adalah langsung "membereskan" semuanya. Refactor bagian yang jelek, upgrade stack, sekalian rewrite biar rapi. Semua insting itu salah waktu. Belum ada yang tahu sistem ini sebenarnya mengerjakan apa; mustahil membedakan perbaikan dari perusakan.

Langkah nol: jalankan dulu, nilai belakangan

Sebelum menyentuh satu file pun dengan niat mengubahnya, sistemnya harus jalan dulu di mesin yang saya kuasai penuh. "Di production aman kok" bukan bukti — itu cerita. Clone repo-nya, install dependency di versi yang benar-benar dipakai, sambungkan ke data nyata, lalu lihat sendiri apakah dia mau boot.

Dari sini keluar inventaris jujur pertama dari engagement-nya. Environment variable mana yang ternyata menopang segalanya. Cron job mana yang tidak pernah disebut siapa pun. API key mana yang di-hardcode di file config lama. Membaca kode tidak akan menunjukkan semua itu — yang menunjukkan adalah menjalankannya, lalu mengamati apa yang pecah.

Lompati langkah ini, dan semua keputusan setelahnya jadi tebak-tebakan. Yang tidak bisa dijalankan, tidak bisa diubah dengan aman.

Backup dan monitoring, sebelum fitur

Begitu sistem jalan di lokal, langkah berikutnya bukan fitur. Langkah berikutnya memastikan production sanggup selamat dari kesalahan berikutnya — kesalahan saya, atau siapa pun. Sistem yang bertahun-tahun jalan tanpa pengawas dan tanpa pemilik yang jelas biasanya begini: backup-nya jalan atau tidak, tidak ada yang tahu. Bisa di-restore atau tidak, apalagi.

Dua hal ini masuk paling depan, sebelum perubahan fungsional apa pun:

• Backup yang terbukti bisa di-restore. Bukan cron job pg_dump ke folder yang tidak pernah dicek siapa pun, tapi restore yang benar-benar dicoba. Dump file yang belum pernah di-restore bukan backup; itu harapan.
• Monitoring dan alerting. Uptime, error rate, sisa disk, panjang antrean — apa pun mode gagal nyata sistem itu. Sistem tumbang jam 2 pagi? Harus ada yang tahu sebelum klien menelepon sambil marah.

Urutan ini tidak bisa ditawar, karena cuma di titik ini biaya melewatkannya tidak ada plafonnya. Fitur yang telat harganya satu sprint. Kehilangan data di sistem yang baru diambil alih harganya klien itu sendiri — mungkin juga reputasi di mata semua orang yang dia kenal.

Characterization test: rekam perilaku sekarang, bukan yang seharusnya

Sistem sudah jalan dan sudah terlindungi. Pertanyaan berikutnya: bagaimana mengubahnya tanpa merusak? Test-driven development biasa berangkat dari perilaku yang sudah diketahui benar. Di sistem warisan tanpa dokumentasi dan tanpa penulis aslinya, perilaku "yang benar" itu sering tidak ada yang tahu. Yang ada cuma perilaku sekarang — lengkap dengan segala keanehannya — dan pengguna sudah bertahun-tahun bergantung justru pada keanehan itu.

Michael Feathers menamai jawabannya characterization test: test yang mendokumentasikan perilaku saat ini, bukan mencocokkan ke spesifikasi. Katanya: "instead of trying to figure out whether code is correct or not, we can try to characterize its behavior to understand what it actually does." Sistem yang sudah di production adalah spesifikasi bagi dirinya sendiri. Suka atau tidak.

Pilih dua-tiga alur yang paling dipertaruhkan bisnis — checkout, pembuatan invoice, job rekonsiliasi tengah malam — lalu tulis test yang mengunci output-nya hari ini. Definisi legacy code versi Feathers bukan "kode lama". Definisinya kode tanpa test. Characterization test itulah yang memberi pijakan untuk kode yang belum layak dipercaya.

Strangler fig: ganti bagian terburuk, bukan semuanya

Backup terpasang, monitoring hidup, jaring characterization test terbentang. Sekarang boleh mulai membenahi — tapi bukan lewat rewrite. Pola yang pas di sini adalah strangler fig application yang dinamai Martin Fowler, dari pohon ara pencekik: tanaman yang membelit inangnya pelan-pelan sampai menggantikannya. Fungsi baru dibangun berdampingan dengan sistem lama. Traffic dialihkan ke sana lewat facade — lapisan perantara yang menyamarkan sistem lama di belakangnya — dan porsinya makin lama makin besar. Kode lama pensiun begitu jalur baru terbukti.

Argumen Fowler untuk pola ini dibanding rewrite ada di risikonya: "the reduced risk and earlier value from the gradual approach outweigh its costs." Padahal facade-nya sendiri cuma scaffolding yang ujung-ujungnya dibuang. Di atas kertas, total jam engineering-nya memang lebih banyak daripada rewrite bersih. Tetap sepadan — karena sepanjang pembangunan ulang, sistemnya tetap jalan dan bisnisnya tetap jualan.

Mulai dari subsistem terburuk — yang paling rajin bikin insiden — dan cekik yang itu dulu. Yang sudah jalan baik, jangan diganggu.

Kenapa "rewrite saja" biasanya opsi termahal

Cepat atau lambat, setiap rescue engagement memunculkan klien yang bertanya: kenapa tidak mulai dari nol saja, sekalian pakai arsitektur yang bersih? Jawaban jujurnya: rewrite total hampir selalu jadi opsi termahal di atas meja, dan makin tua sistemnya, makin besar risikonya.

Studi kasus klasiknya cerita Joel Spolsky soal Netscape yang me-rewrite Navigator dari nol. Ia menyebut keputusan itu "the single worst strategic mistake that any software company can make." Rewrite-nya makan waktu sekitar tiga tahun — dan selama itu kompetitor menggerogoti pangsa pasar browser mereka.

Inti argumennya yang paling kena di sini: "when you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work." Kode legacy yang jelek sering kali jelek justru karena ia menyimpan tambalan atas insiden nyata yang sudah tidak diingat siapa pun. Rewrite membuang tambalan itu sekaligus ingatannya — dan menghadiahkan ke kompetitor, meminjam kata Spolsky, "a gift of two or three years."

Kapan rewrite total memang tepat

Kasus sempitnya memang ada, dan perlu disebut supaya tidak tertukar dengan kasus yang cuma terasa menggoda. Rewrite tepat kalau platformnya sendiri sudah tidak bisa diselamatkan: runtime yang tidak lagi dapat patch keamanan, framework yang maintainer-nya sudah bubar. Di-test sebanyak apa pun, fakta itu tidak berubah. Rewrite juga tepat kalau sistemnya memang kecil — saat cap "legacy" terdengar lebih seram daripada risiko aslinya.

Yang tidak masuk hitungan: kode yang sekadar jelek dipandang, stack yang tidak disukai tim sekarang, atau rewrite yang diajukan karena mulai dari nol terdengar lebih enak daripada membaca keputusan orang lain. Semua itu keberatan estetika yang berpakaian teknis. Dan jujur saja, mayoritas permintaan rewrite yang mampir ke saya masuk golongan ini.

Menjual stabilize-first ke klien yang minta "dibangun ulang yang benar"

Klien minta rewrite karena "dibangun ulang yang benar" terdengar seperti kemajuan, sementara "stabilkan dulu yang ada" terdengar seperti jalan di tempat. Pitch yang berhasil tidak mengubah tujuannya — cuma membetulkan urutannya. Stabilisasi itulah yang membuat rebuild aman jadi mungkin. Lewat strangler fig, rebuild-nya tetap datang, dicicil subsistem demi subsistem, tanpa fitur baru harus dibekukan bertahun-tahun.

Soal developer lama yang pergi, bicarakan apa adanya. Satu orang memegang seluruh pengetahuan yang tidak tertulis — itu sudah titik kegagalan tunggal jauh sebelum ada yang datang menolong. Rewrite oleh tim baru tanpa jaring characterization test cuma melahirkan kerapuhan yang sama dengan nama baru.

Backup, monitoring, characterization test — itu bukan jalur lambat. Justru itu yang membuat semua langkah sesudahnya cepat, karena akhirnya ada cara memastikan: perubahan ini membuat sistem lebih baik, atau lebih buruk.