Program lama kadang masih bekerja dengan baik. Persoalannya baru terlihat ketika seseorang harus mengubah satu bagian tanpa merusak puluhan bagian lain yang bergantung kepadanya.
Bayangkan sebuah sistem pembayaran yang telah digunakan selama dua puluh tahun. Setiap hari jutaan transaksi melewatinya, pegawai sudah hafal cara mengoperasikannya, dan berbagai sistem lain terhubung kepadanya. Lalu muncul permintaan yang terdengar sederhana: tambahkan satu fitur baru.
Bagi orang di luar tim pengembang, pekerjaan itu mungkin terlihat seperti menambahkan beberapa baris kode. Bagi programmer yang membuka sistem tersebut, ceritanya bisa sama sekali berbeda karena satu fungsi ternyata memanggil fungsi lain, terhubung dengan basis data lama, lalu digunakan oleh aplikasi yang bahkan dibuat tim berbeda bertahun-tahun sebelumnya. Mengubah satu bagian tanpa memahami hubungan tersebut mirip memperbaiki satu pipa di rumah tua tanpa mengetahui pipa mana yang ternyata memasok air ke seluruh bangunan.
Masalah seperti ini bukan sekadar cerita dari perusahaan teknologi kecil. U.S. Government Accountability Office [GAO] pada Juli 2025 mengidentifikasi 11 sistem teknologi informasi federal Amerika Serikat yang paling membutuhkan modernisasi, dengan usia antara sekitar 23 sampai 60 tahun. Delapan di antaranya masih menggunakan bahasa pemrograman lama seperti COBOL dan assembly language, sementara sejumlah sistem tetap menopang fungsi penting seperti pemrosesan pajak, layanan kesehatan, infrastruktur, dan keamanan nasional.
Baca Juga: Kenapa Aplikasi yang Dulu Cepat Lama-Lama Terasa Berat?
Program Lama Membawa Sejarah yang Tidak Terlihat di Dalam Kodenya
Istilah legacy system sering diterjemahkan terlalu sederhana sebagai sistem tua. Padahal usia bukan satu-satunya persoalan, karena sebuah program menjadi sulit disentuh ketika terlalu banyak proses, keputusan, kebiasaan, dan sistem lain telah bergantung kepadanya. Kode yang terlihat aneh hari ini bahkan mungkin dibuat untuk menyelesaikan masalah yang sangat masuk akal lima belas tahun lalu.
Di sinilah programmer sering berhadapan dengan sesuatu yang disebut technical debt. Sebuah tim mungkin pernah mengambil jalan lebih cepat agar produk selesai sebelum tenggat, menambahkan solusi sementara, atau mempertahankan struktur lama karena bisnis tidak bisa berhenti. Keputusan itu membantu pada waktunya, tetapi setiap lapisan baru membuat biaya memahami dan mengubah program tersebut perlahan bertambah.
Ada pula bagian program yang tidak berani disentuh bukan karena siapa pun tahu pasti fungsinya, melainkan karena semua orang tahu akibatnya bisa tidak menyenangkan. Dokumentasinya mungkin tidak lengkap, pembuat awalnya sudah pindah perusahaan, sementara pengujian otomatis belum mencakup seluruh perilaku sistem. Kode semacam ini kadang bertahan bukan karena dianggap bagus, tetapi karena kalimat 'selama masih jalan, jangan disentuh' terasa lebih aman.
GAO memberikan gambaran konkret mengenai beban tersebut. Sebelas sistem kritis yang diidentifikasinya menghabiskan sekitar US$754 juta setiap tahun untuk operasi dan pemeliharaan, sementara sebagian menghadapi keterbatasan tenaga yang masih menguasai teknologi lamanya. Pada salah satu sistem Departemen Pertahanan yang teknologinya berasal dari 1964, GAO mencatat semakin terbatasnya personel dan keahlian vendor yang mampu mempertahankan infrastruktur berbasis COBOL dan assembly language.
Keadaan tersebut membuat satu permintaan perubahan harus diperlakukan dengan hati-hati. Programmer bukan hanya bertanya bagaimana membuat fitur baru bekerja, tetapi juga apa yang mungkin ikut berhenti bekerja setelahnya. Semakin penting fungsi program lama, semakin mahal pula harga sebuah kesalahan kecil.
Baca Juga: Coding Itu Belajar Bahasa Komputer atau Belajar Cara Berpikir?
Membuat Ulang dari Nol Terdengar Mudah, Sampai Semua yang Lama Harus Dibangun Kembali
Pilihan yang terdengar paling bersih tentu membuang program lama dan membuat versi baru. Kodenya bisa memakai teknologi modern, strukturnya lebih rapi, dan tim tidak perlu terus bernegosiasi dengan keputusan teknis dari masa lalu. Namun membuat dari nol berarti pengetahuan yang tersembunyi di dalam sistem lama juga harus ditemukan dan diterjemahkan kembali.
Joel Spolsky, programmer dan salah satu pendiri Stack Overflow, pernah memperingatkan keras mengenai godaan tersebut melalui esainya Things You Should Never Do, Part I. Ia menggunakan Netscape sebagai contoh perusahaan yang memutuskan menulis ulang kode dari awal dan kemudian membutuhkan waktu panjang sebelum versi baru siap. Bagi Spolsky, kode lama mungkin terlihat berantakan, tetapi banyak bagian di dalamnya merupakan hasil perbaikan terhadap ribuan masalah yang pernah ditemukan sepanjang usia program tersebut.
Sebuah pengecekan yang tampak tidak penting mungkin sebenarnya ditambahkan setelah kejadian tertentu sepuluh tahun lalu. Sebuah urutan proses yang terlihat tidak elegan bisa saja dibuat karena sistem lain hanya mampu menerima data dalam urutan tersebut. Ketika semuanya ditulis ulang, aturan-aturan kecil yang tidak terdokumentasi itu berisiko hilang sampai pengguna menemukan kembali masalahnya dengan cara yang lebih mahal.
Itulah sebabnya modernisasi sistem sering dilakukan bertahap, bukan melalui satu tombol besar bernama 'ganti semuanya'. Bagian tertentu dapat dipisahkan, antarmuka lama diganti sedikit demi sedikit, pengujian diperbanyak, dokumentasi diperbaiki, lalu fungsi kritis dipindahkan ketika risikonya sudah dipahami. Pekerjaannya mungkin terlihat lebih lambat dibandingkan membuat proyek baru di layar kosong, tetapi organisasi tetap harus beroperasi sementara renovasi berlangsung.
Program baru memang mempunyai kemewahan yang jarang dimiliki program lama: belum banyak orang bergantung kepadanya. Kesalahan masih bisa diperbaiki sebelum jutaan transaksi, data pelanggan, pekerjaan pegawai, dan aplikasi lain ikut tersambung. Program lama membawa beban yang berbeda karena setiap keberhasilannya selama bertahun-tahun justru membuat semakin banyak sesuatu dibangun di atasnya.
Karena itu, kode lama yang terlihat kusut belum tentu sekadar bukti programmer masa lalu bekerja buruk. Bisa jadi ia adalah lapisan sejarah dari perubahan bisnis, pergantian teknologi, masalah yang pernah terjadi, dan solusi yang ditambahkan satu demi satu agar sistem tetap hidup. Membuat program baru berarti menulis kode, sedangkan memperbaiki program lama sering berarti membaca sejarah sebelum berani mengubah satu kalimat di dalamnya. [][Rudi Tenggarawan/KK]
Penulisan artikel ini dibantu AI dan telah melewati proses kurasi Redaksi.
