Setiap developer yang mewarisi sistem lama pernah merasakannya: baru satu jam membaca kode, dan keinginan menulis ulang dari nol sudah muncul. Perasaan itu hampir selalu salah, tapi kadang benar. Masalahnya, membedakan keduanya butuh bukti, bukan kesan.
Tulisan ini soal cara memeriksa sistem warisan secara terstruktur, supaya rekomendasi Anda bisa dipertahankan di depan orang yang memegang anggaran.
Kenapa Rewrite Biasanya Kalah
Sistem lama yang berantakan itu jelek, tapi ia punya satu keunggulan yang sering diremehkan: ia sudah melewati bertahun-tahun kasus nyata. Setiap kondisi aneh yang pernah terjadi sudah ada penanganannya di sana, sering dalam bentuk if yang tidak masuk akal sampai Anda tahu ceritanya.
Rewrite memulai dari nol, termasuk nol pengalaman. Anda akan menemukan kembali semua kasus tepi itu satu per satu, di production, dengan pengguna sungguhan sebagai pengujinya.
Jadi titik awalnya bukan “haruskah ditulis ulang”, melainkan “apa yang sebenarnya rusak, seberapa parah, dan apakah bisa diperbaiki bertahap”.
Mulai dari Keamanan, Bukan Estetika
Kode jelek membuat pengembangan lambat. Lubang keamanan membuat data bocor. Keduanya masalah, tapi hanya satu yang bisa menghabisi organisasi dalam semalam.
Periksa lebih dulu hal-hal yang dampaknya tidak bisa dibatalkan:
Injeksi SQL. Cari query yang dirangkai dengan penggabungan string. Di PHP warisan, polanya biasanya terlihat begini:
$q = "SELECT * FROM users WHERE email = '" . $_POST['email'] . "'";Satu saja yang lolos sudah cukup untuk membaca seluruh basis data.
Penyimpanan kata sandi. Cari md5( atau sha1( di sekitar kata sandi. Keduanya bukan fungsi hashing kata sandi dan bisa dipecahkan dengan tabel siap pakai. Yang benar adalah bcrypt, scrypt, atau Argon2.
Kredensial di dalam repositori. Telusuri riwayat Git, bukan hanya kondisi terakhir. Secret yang pernah masuk riwayat tetap bisa diambil meski berkasnya sudah dihapus.
Otorisasi yang hanya di antarmuka. Menyembunyikan tombol hapus dari pengguna biasa bukan kontrol akses. Periksa apakah endpoint-nya sendiri memeriksa peran, atau hanya mengandalkan pengguna tidak tahu alamatnya.
Unggahan berkas. Apakah ekstensi divalidasi? Apakah berkas disimpan di direktori yang bisa dieksekusi? Unggahan gambar yang ternyata bisa menjalankan PHP adalah jalan pintas menuju server.
Untuk tiap temuan, catat tiga hal: letaknya di berkas mana, apa dampaknya kalau dimanfaatkan, dan seberapa sulit dieksploitasi. Tanpa ketiganya, temuan Anda hanya terbaca sebagai keluhan.
Ukur, Jangan Cuma Merasa
“Kodenya berantakan” tidak bisa dibantah maupun dibuktikan. Angka bisa.
Beberapa ukuran yang murah didapat dan mudah dijelaskan ke orang non-teknis:
- Jumlah baris per berkas, dan berapa berkas yang melewati seribu baris
- Duplikasi kode, berapa persen isi repositori yang pada dasarnya salinan
- Kedalaman percabangan, fungsi dengan
ifbersarang lima tingkat adalah tanda bahaya - Cakupan pengujian, dan kalau nol, sebutkan nol
- Jumlah dependensi yang sudah tidak dirawat atau punya kerentanan diketahui
- Berapa lama waktu dari mengubah satu baris sampai bisa dilihat hasilnya
Yang terakhir itu sering paling meyakinkan. Kalau mengubah satu label butuh deploy manual empat puluh menit, itu biaya yang bisa dihitung per bulan.
Alat seperti PHPStan, SonarQube, atau npm audit bisa memberi sebagian angka ini tanpa Anda membaca satu berkas pun.
Petakan Apa yang Sebenarnya Dipakai
Sistem warisan hampir selalu lebih kecil dari kelihatannya. Banyak menu yang tidak pernah diklik siapa pun sejak lama.
Sebelum memperkirakan usaha, cari tahu bagian mana yang hidup. Log akses server adalah sumber termurah. Kalau ada, analitik juga membantu. Kalau keduanya tidak ada, tanya pengguna langsung: fitur apa yang Anda pakai setiap hari, setiap bulan, dan tidak pernah.
Hasilnya sering mengejutkan. Modul yang paling menakutkan di kode ternyata dipakai dua kali setahun, sementara yang dipakai setiap hari justru sederhana. Itu mengubah prioritas secara drastis.
Tulis Temuannya untuk Dua Pembaca
Laporan audit yang hanya bisa dibaca programmer akan berhenti di meja programmer. Padahal yang memutuskan anggaran biasanya bukan programmer.
Susun dua lapis. Ringkasan di depan berisi kondisi saat ini, risiko terbesar, dan pilihan tindakan beserta perkiraan biaya. Detail teknis di belakang, lengkap dengan letak berkas dan cara reproduksi, untuk yang akan mengerjakan.
Untuk risiko, hindari kata sifat. Bukan “keamanannya lemah”, melainkan “data seluruh pengguna termasuk nomor telepon dapat diambil oleh siapa pun tanpa login, lewat satu permintaan ke halaman X”.
Tiga Pilihan, Bukan Dua
Pertanyaan “perbaiki atau tulis ulang” adalah pilihan palsu. Hampir selalu ada jalan ketiga.
Perbaiki di tempat. Cocok kalau arsitekturnya masih masuk akal dan masalahnya terpusat. Paling murah, paling tidak berisiko.
Cekik bertahap. Bangun sistem baru di sebelahnya, pindahkan satu modul dalam satu waktu, taruh proxy di depan supaya pengguna tidak tahu bedanya. Lebih lama, tapi sistem lama tetap jalan selama transisi dan setiap langkah bisa dibatalkan.
Tulis ulang penuh. Masuk akal hanya kalau teknologinya benar-benar tidak lagi didukung, atau kebutuhan bisnisnya sudah berubah total sehingga sistem lama menjawab pertanyaan yang salah.
Sajikan ketiganya dengan perkiraan waktu dan risiko masing-masing. Membiarkan pemangku kepentingan memilih dari tiga opsi jauh lebih mungkin menghasilkan keputusan daripada menyodorkan satu tuntutan.
Apa pun Keputusannya, Pasang Jaring Dulu
Kalau hasilnya perbaikan bertahap, jangan langsung menyentuh kode. Pasang dulu hal-hal yang membuat perubahan aman:
- Backup yang sudah diuji pemulihannya
- Pengujian karakterisasi pada alur paling kritis, sekadar mengunci perilaku saat ini apa adanya
- Pemantauan error, supaya Anda tahu ada yang rusak sebelum pengguna menelepon
- Lingkungan staging yang datanya menyerupai production
Pengujian karakterisasi itu terasa aneh karena Anda menulis pengujian untuk perilaku yang mungkin salah. Tapi tujuannya bukan membuktikan kode benar, melainkan memastikan perubahan Anda tidak mengubah apa pun yang tidak Anda niatkan.
Penutup
Audit yang baik mengubah percakapan dari selera menjadi bukti. Setelah ada daftar risiko yang konkret, angka yang bisa dibandingkan, dan tiga pilihan dengan konsekuensinya masing-masing, keputusan biasanya jadi jelas dengan sendirinya. Dan tidak jarang kesimpulannya bukan rewrite, melainkan tiga minggu perbaikan terarah yang menyelesaikan delapan puluh persen keluhan.