Legacy dalam Pengembangan Aplikasi — Apa Itu, Risiko, dan Strategi Kerja

Apa itu Legacy dalam Pengembangan Aplikasi

Legacy — kode atau sistem yang masih berjalan di produksi tetapi tidak lagi memenuhi standar kualitas modern. Legacy bisa ditulis dalam bahasa usang (misalnya Objective-C daripada Swift), menggunakan pustaka yang tidak didukung atau pola arsitektur yang sudah lama dianggap antipola.

Ciri utama legacy adalah kurangnya tes. Menurut definisi Michael Feathers (2004), kode legacy adalah kode tanpa tes. Jika perilaku tidak dapat diubah dengan aman, sistem berstatus legacy terlepas dari usianya. Kode segar tanpa tes unit — adalah legacy hari pertama.

Legacy belum tentu buruk. Sistem yang dirancang dengan baik di Java 8 bisa lebih andal dan mudah dipahami daripada kode kacau di Kotlin dengan coroutine. Usia kode bukan indikator kualitas — yang penting adalah seberapa mudah sistem dapat diubah dan diperluas.

Mengapa Legacy Code Itu Normal

Setiap sistem yang sukses seiring waktu menjadi legacy. Ini adalah proses alami: teknologi berkembang lebih cepat daripada kode dapat ditulis ulang. Aplikasi yang ditulis 5 tahun lalu di Swift 2 hari ini adalah legacy, meskipun pada saat pembuatan ia modern.

Nilai bisnis legacy sering diremehkan. Sistem bekerja stabil, memproses transaksi, menyimpan data — penulisan ulang membawa risiko. Menurut Standish Group (2024), 35% proyek penulisan ulang total berakhir dengan kegagalan. Secara ekonomi, tidak membuang legacy, tetapi belajar bekerja dengannya lebih dibenarkan.

Strategi terbaik — migrasi bertahap, enkapsulasi kode lama di balik antarmuka baru, dan pengujian otomatis. Legacy menjadi masalah hanya ketika ia berhenti dapat diubah dengan biaya yang dapat diprediksi.

Tanda-Tanda Utama Sistem Legacy

Kurangnya tes otomatis — indikator utama. Jika setelah mengubah satu baris kode, pengembang tidak dapat menjalankan tes dan memastikan tidak ada yang rusak — Anda berhadapan dengan legacy. Tanda tambahan: prosedur deployment memakan waktu berjam-jam dan memerlukan tindakan manual.

Dokumentasi tidak sesuai dengan kode — tanda lainnya. Diagram arsitektur sudah usang, komentar menggambarkan perilaku yang sudah berubah. Time-to-ramp-up untuk pengembang baru melebihi satu bulan — tanda kompleksitas tinggi dan maintainability rendah sistem.

Tanda tambahan: arsitektur monolitik tanpa batas yang jelas, pengujian manual sebagai metode verifikasi utama, pipeline CI panjang (lebih dari 30 menit), penggunaan pustaka tanpa versi terkini, dan ketidakmampuan memperbarui dependensi tanpa merusak modul tetangga.

Fenomena “kode rapuh” — perubahan di satu tempat merusak tiga tempat lain. Ini adalah konsekuensi dari pengikatan ketat (tight coupling), ketika modul terlalu banyak tahu satu sama lain. Semakin tinggi coupling, semakin cepat sistem berpindah ke kategori legacy.

Risiko Bekerja dengan Kode Usang

Penurunan kecepatan — risiko utama. Menambahkan fitur sederhana membutuhkan waktu berjam-jam untuk mempelajari kode dan berhari-hari untuk pengujian. Menurut Stripe (2024), pengembang menghabiskan 33% waktu untuk mengatasi utang teknis, yang terkait langsung dengan keberadaan modul legacy dalam proyek.

Kebocoran keahlian — penulis kode asli meninggalkan perusahaan dan dokumentasi tidak lengkap. Pengembang baru takut menyentuh modul yang tidak dipahami, yang menyebabkan efek “kode beku”: modul tidak berkembang tetapi terus berfungsi. Bus factor sistem semacam itu sangat rendah.

Keamanan — pustaka usang mengandung kerentanan yang diketahui. Menggunakan OpenSSL 1.0.2 atau versi Jackson yang usang di proyek Java adalah jalan langsung menuju insiden keamanan yang dapat merugikan bisnis dari segi reputasi dan pelanggan.

Demotivasi tim — bekerja dengan legacy tanpa strategi perbaikan mengurangi kepuasan pengembang. Tim berhenti bangga dengan produk, pergantian karyawan meningkat, yang semakin memperlambat pengembangan sistem.

Strategi Refactoring Legacy

Tes karakterisasi — langkah pertama sebelum perubahan apa pun pada kode legacy. Jalankan kode pada data input yang diketahui dan catat output yang diharapkan. Tes ini mencatat perilaku saat ini sebagai spesifikasi. Golden master testing — varian di mana data output dibandingkan dengan file referensi.

Analisis seam — mencari titik di mana pengikatan dapat diputus tanpa mengubah perilaku. Michael Feathers membedakan beberapa jenis seam: preprocessor seam, object seam, link seam. Object seam — yang paling umum: penggantian objek nyata dengan stub tes melalui antarmuka.

Sprout method dan Sprout class — teknik menambahkan kode baru di samping kode lama, bukan di dalamnya. Alih-alih memodifikasi metode yang ada, buat metode baru dengan logika yang diperlukan dan panggil dari metode lama. Ini meminimalkan risiko merusak kode yang berfungsi.

Contoh: menambahkan logging di legacy

class LegacyPaymentProcessor {
    def process(payment) {
        // 200 baris kode legacy yang tidak boleh disentuh
        logPayment(payment) // sprout method
    }
    def logPayment(payment) {
        // kode baru ditambahkan di samping legacy
    }
}

Migrasi ke Tumpukan Teknologi Modern

Pola Strangler Fig — pendekatan yang direkomendasikan untuk migrasi legacy. Modul baru dibuat secara paralel, lalu lintas secara bertahap dialihkan dari lama ke baru. Modul lama “mati” secara alami ketika berhenti menerima permintaan. Pola ini meminimalkan risiko dan memungkinkan rollback jika terjadi masalah.

Branch by Abstraction — teknik di mana abstraksi dibuat di atas implementasi lama dan baru. Kode klien beralih ke abstraksi, implementasi lama secara bertahap digantikan oleh yang baru. Contoh: penggantian lapisan jaringan dari AFNetworking ke Alamofire melalui protokol tunggal NetworkService.

Migrasi bertahap — pembagian transisi menjadi langkah-langkah kecil: enkapsulasi modul lama → menulis tes → membuat modul baru → menjalankan paralel → menghapus modul lama. Setiap langkah diakhiri dengan status sistem yang stabil, memungkinkan deployment perubahan kapan saja.