Setiap beberapa bulan, ada klien yang bilang sistem lama mereka "sudah tidak bisa di-maintain" dan bertanya seberapa cepat kita bisa membangunnya ulang dari nol. Pertanyaan rewrite vs refactor ini kedengarannya teknis, tapi sebenarnya ini soal risiko dan arus kas yang menyamar sebagai masalah teknis. Salah ambil keputusan, dan perusahaan bisa terjebak dua tahun tanpa fitur baru, atau terus menggelontorkan budget maintenance ke sistem yang melawan tim setiap sprint.
Saya sudah berada di kedua sisi keputusan ini: sebagai engineer yang mengusulkan rencana, dan sebagai orang yang dipanggil beberapa bulan kemudian untuk menjelaskan ke pemilik bisnis kenapa rewrite yang harusnya selesai dalam empat bulan kini sudah masuk bulan keempat belas tanpa tanggal rilis. Polanya cukup bisa ditebak sehingga saya punya satu jawaban default, dan saya ingin menjelaskan kenapa, sekaligus kondisi-kondisi spesifik di mana saya justru merekomendasikan sebaliknya.
Jawaban default saya, hampir selalu, adalah refactor secara bertahap. Rewrite dari nol adalah pengecualian, bukan langkah standar, dan memperlakukannya sebagai langkah standar adalah cara perusahaan membakar ratusan juta hingga miliaran rupiah untuk sistem yang pada akhirnya melakukan hal yang sama seperti sistem lama, hanya lebih baru.
Kenapa Insting untuk Rewrite Biasanya Keliru
Rewrite terasa memuaskan karena menjanjikan lembaran bersih. Tidak ada lagi workaround, tidak ada lagi kode yang tidak dipahami siapa pun, tidak ada lagi "modul itu jangan disentuh." Tapi rewrite penuh punya tiga karakteristik yang jarang diungkap secara terbuka sebelum proyek dimulai.
Pertama, tim jadi beku. Selama sistem baru dibangun, sistem lama tetap harus menjalankan bisnis, sehingga perusahaan membayar dua biaya engineering sekaligus: memelihara sistem legacy dan membangun penggantinya. Permintaan fitur dari bisnis akan diminta menunggu "sistem baru," yang biasanya berarti enam bulan berubah jadi dua belas bulan.
Kedua, perusahaan kehilangan business logic yang terakumulasi tanpa disadari keberadaannya. Kode legacy penuh dengan perbaikan kecil, jelek, dan tidak terdokumentasi untuk kasus-kasus khusus: pelanggan yang dapat kode diskon spesial, cabang yang menghitung pajak sedikit berbeda, format laporan yang diminta salah satu manajer keuangan pada 2019. Semua itu tidak ada di spesifikasi mana pun. Semua itu hidup di kode yang berjalan. Tim rewrite akan mengimplementasikan ulang versi bersih dari business logic dan diam-diam menghilangkan kasus-kasus khusus tersebut, yang baru muncul sebagai bug setelah peluncuran, di production, di depan pelanggan.
Ketiga, rewrite punya pola kegagalan yang sudah dikenal luas, yang saya sebut spiral kematian rewrite dua tahun. Bulan pertama sampai ketiga: penuh semangat, diagram arsitektur bersih, progres cepat di bagian-bagian mudah. Bulan keempat sampai kedelapan: 20 persen bagian tersulit (kasus-kasus khusus, integrasi, perilaku aneh sistem lama) mulai menggerogoti estimasi. Bulan kesembilan sampai kelima belas: bisnis, yang sudah lelah menunggu, mulai meminta fitur baru ditambahkan ke sistem legacy juga, sehingga sekarang ada dua target yang sama-sama bergerak. Bulan keenam belas dan seterusnya: scope sistem baru sudah membengkak mengejar sistem legacy yang juga ikut berubah. Tidak ada lagi kesepakatan soal definisi "selesai," dan proyek akhirnya dibatalkan setelah biaya yang sudah terlanjur keluar sangat besar, atau dirilis secara terburu-buru dan kembali memunculkan sebagian besar masalah awal dalam waktu satu tahun.
Yang Saya Rekomendasikan Sebagai Gantinya: Pendekatan Strangler
Pola strangler, dinamai dari pohon ara pencekik (strangler fig) yang tumbuh mengelilingi pohon inang dan perlahan menggantikannya, menyelesaikan masalah pembekuan secara langsung. Perusahaan tidak menghentikan sistem lama untuk membangun yang baru. Sistem baru dibangun secara bertahap, mengelilingi sistem lama, mengalihkan traffic ke bagian baru hanya setelah bagian itu terbukti berfungsi, sementara sisa aplikasi tetap berjalan tanpa perubahan.
Dalam praktiknya, untuk aplikasi bisnis pada umumnya, langkahnya seperti ini:
- Pasang lapisan routing di depan aplikasi legacy. Biasanya cukup reverse proxy atau API gateway yang menentukan, per request, apakah dilayani oleh sistem lama atau baru.
- Pilih modul dengan risiko paling rendah dan paling terisolasi lebih dulu. Bukan mesin order inti. Sesuatu seperti modul reporting atau layar admin yang berdiri sendiri, dengan blast radius kecil kalau ada yang salah.
- Bangun ulang modul itu dengan benar, lengkap dengan tes, lalu alihkan traffic ke sana. Sisa aplikasi tidak akan menyadarinya.
- Ulangi, modul demi modul, bergerak menuju bagian paling berisiko dan paling sentral di akhir, setelah tim punya kepercayaan diri dan pola routing sudah terbukti.
- Pensiunkan kode legacy hanya setelah tidak ada lagi traffic yang diarahkan ke sana.
Cara ini memang lebih lambat untuk memperlihatkan sistem yang sepenuhnya baru, tapi tidak pernah membekukan pengiriman fitur, tidak pernah menggandakan biaya operasional selama setahun penuh, dan setiap bagian dirilis serta diuji dengan traffic sungguhan sebelum bagian berikutnya dimulai. Jika proses bisnisnya sendiri belum jelas sebelum menyentuh kode, petakan dulu. Mencekik proses yang tidak terdokumentasi hanya memindahkan kebingungan ke kode yang baru.
Kapan Rewrite Benar-Benar Menjadi Pilihan yang Tepat
Saya pernah merekomendasikan rewrite penuh, tapi hanya ketika sebagian besar kondisi berikut berlaku sekaligus:
| Kondisi | Kenapa Ini Penting |
|---|---|
| Teknologinya benar-benar sudah mati | Tidak ada talent yang tersedia, tidak ada security patch, vendor sudah berhenti total memberikan dukungan |
| Arsitektur secara aktif menghambat bisnis | Tidak bisa menambah gudang kedua, mata uang kedua, negara kedua, tanpa membangun ulang inti sistem |
| Sistemnya cukup kecil untuk di-rewrite dalam waktu kurang dari tiga bulan | Blast radius kecil, risiko sunk cost kecil kalau ternyata salah |
| Tim asli atau dokumentasi lengkap masih tersedia | Masalah hilangnya pengetahuan kasus khusus tidak berlaku kalau seluruh logic-nya memang sudah dipahami |
| Bisnis bisa menoleransi hard cutover | Jarang terjadi untuk sistem customer-facing berskala besar |
Perhatikan betapa sempitnya daftar ini. Sebuah perusahaan multifinance yang pernah saya tangani memiliki sistem loan origination di atas stack yang benar-benar sudah tidak didukung, tanpa developer yang tersedia di pasar, tanpa patch dari vendor, dan sistemnya cukup kecil (beberapa layar, satu alur kerja inti) sehingga rewrite muat dalam satu kuartal. Itu rewrite yang sah. Sebuah jaringan retail di Tangerang yang ingin "memodernisasi" sistem point-of-sale yang masih berfungsi hanya karena kodenya terlihat lama, itu bukan kasus yang sah: sistemnya berfungsi, tim masih bisa merekrut untuk stack tersebut, dan keluhan sebenarnya hanya tiga laporan spesifik yang lambat, yang kami perbaiki dengan refactoring terarah dalam tiga minggu, bukan rewrite yang akan memakan waktu satu tahun.
Pertanyaan yang Harus Dijawab Sebelum Memutuskan
Sebelum berkomitmen ke salah satu arah, paksa diri untuk menjawab jujur pertanyaan-pertanyaan ini:
- Apa yang secara spesifik rusak: performa, satu alur kerja, kesulitan rekrutmen, keamanan, atau ini sekadar ketidaknyamanan estetika terhadap kode lama?
- Bisakah kita menyebut satu modul yang paling menyakitkan, dan apakah memperbaiki modul itu saja bisa menyelesaikan 80 persen keluhan?
- Berapa toleransi kita untuk menjalankan dua sistem secara paralel, dalam hitungan bulan dan budget?
- Siapa yang saat ini memahami kasus-kasus khusus di sistem ini, dan apakah mereka masih bisa dihubungi?
- Kalau kita salah memperkirakan scope sebesar 50 persen, pendekatan mana yang gagal dengan lebih aman?
Pertanyaan terakhir itu biasanya yang menentukan. Pendekatan strangler yang molor tetap menghasilkan sistem yang bekerja dan sudah membaik, hanya sedikit terlambat. Rewrite yang molor tidak menghasilkan apa-apa, dalam waktu yang lama, sementara tagihan terus berjalan.
Kesimpulan Praktis
Lakukan refactor secara bertahap sebagai default, dan simpan rewrite penuh untuk kasus sempit di mana teknologinya benar-benar mati, sistemnya benar-benar kecil, dan bisnis bisa menyerap hard cutover. Sebelum menyetujui salah satu jalur, minta jawaban lugas soal apa yang secara spesifik rusak, karena "kelihatannya sudah tua" bukan sebuah scope, dan tidak sepadan dengan setahun penuh pengiriman fitur yang beku. Kalau butuh opini kedua soal sistem legacy sebelum keputusan rewrite besar diambil, itulah jenis keputusan yang layak melibatkan pandangan dari luar, dan itu bagian dari yang saya kerjakan lewat model kemitraan saya.