Refactoring Bukan Kemewahan: Catatan dari Basis Kode yang Membusuk Perlahan

Ada satu kalimat yang hampir selalu muncul setiap kali tim pengembang membahas technical debt: "Nanti saja, kita refactor kalau sudah tidak sibuk." Masalahnya, momen "tidak sibuk" itu jarang benar-benar datang. Deadline berikutnya sudah menunggu sebelum yang sekarang selesai, dan kode yang "sementara" itu diam-diam menjadi fondasi permanen.

Saya pernah bekerja di sebuah basis kode yang, kalau dianalogikan sebagai bangunan, sudah seperti rumah yang direnovasi delapan kali oleh delapan kontraktor berbeda tanpa satu pun dari mereka melihat cetak biru aslinya. Setiap fungsi punya gaya penulisan sendiri. Setiap modul punya asumsi implisit yang hanya dipahami satu orang — dan orang itu sudah resign dua tahun lalu.

Bunga majemuk, tapi untuk utang

Technical debt bekerja persis seperti utang finansial: ia punya bunga. Setiap kali kita menambah fitur di atas kode yang berantakan tanpa membereskannya dulu, kita tidak cuma menambah satu lapis kerumitan — kita menambah kerumitan yang harus dinavigasi oleh setiap perubahan berikutnya, selamanya, sampai seseorang membayarnya.

Yang sering tidak disadari tim adalah: bunga ini tidak linear. Kode yang berantakan tidak membuat pekerjaan 10% lebih lambat secara konsisten. Ia membuat pekerjaan semakin lambat secara eksponensial, karena setiap penambahan baru harus mengakomodasi seluruh ketidakteraturan yang sudah menumpuk sebelumnya.

Kode yang jelek tidak menghukum Anda hari ini. Ia menghukum Anda enam bulan dari sekarang, dengan bunga yang sudah berlipat ganda.

Mengapa "nanti saja" selalu kalah

Ada alasan struktural kenapa refactoring selalu kalah prioritas dari fitur baru: fitur baru punya nilai yang terlihat — ada demo, ada stakeholder yang senang, ada nomor di roadmap yang tercoret. Refactoring tidak menghasilkan apa pun yang terlihat dari luar. Aplikasi tampak persis sama sebelum dan sesudahnya.

Ini masalah insentif, bukan masalah kemauan. Selama kesehatan kode tidak diukur dan tidak dilaporkan sama seriusnya dengan kecepatan pengiriman fitur, ia akan selalu kalah dalam kompetisi prioritas. Solusinya bukan menunggu momentum yang tidak akan pernah datang, tapi mengubah cara refactoring dibingkai:

• Jangan minta izin untuk "proyek refactoring besar". Minta izin untuk meninggalkan setiap berkas 5% lebih baik dari saat ditemukan — aturan sederhana yang tidak butuh persetujuan rapat.
• Ikat refactoring ke pekerjaan yang sudah disetujui. Kalau Anda harus menyentuh sebuah modul untuk menambah fitur, itu momen paling murah untuk membereskannya — Anda sudah di sana, sudah memahami konteksnya.
• Ukur, jangan cuma rasakan. Waktu build, jumlah flaky test, waktu rata-rata menyelesaikan satu tiket — angka-angka ini membuat argumen refactoring bisa dipertahankan di depan siapa pun yang tidak menulis kode sehari-hari.

Kapan refactoring justru berbahaya

Bukan berarti refactoring selalu benar dilakukan kapan saja. Membongkar sistem yang sedang berjalan stabil, tanpa cakupan uji yang memadai, semata karena "kodenya jelek" adalah cara tercepat mengubah bug yang tidak pernah muncul menjadi insiden produksi. Kode yang jelek tapi terbukti benar, kadang, lebih berharga daripada kode yang rapi tapi belum teruji.

Pertanyaan yang lebih berguna dari "apakah kode ini jelek?" adalah "apakah ketidakrapian ini yang membuat perubahan berikutnya lambat atau berisiko?" Kalau jawabannya tidak — kalau modul itu jarang disentuh dan jarang salah — biarkan saja. Energi refactoring paling berharga habiskan di jalur yang paling sering dilalui, bukan di sudut yang paling mengganggu mata.

Contoh kecil, yang sering saya pakai untuk menjelaskan ini ke tim: bandingkan fungsi yang melakukan terlalu banyak hal sekaligus versus versi yang dipecah berdasarkan tanggung jawab.

Perubahan ini kecil. Tidak ada fitur baru, tidak ada yang berubah dari sudut pandang pengguna. Tapi enam bulan dari sekarang, ketika seseorang perlu mengubah cara pajak dihitung, mereka tahu persis di mana harus mencari — dan tidak perlu takut merusak validasi atau penyimpanan sambil melakukannya.

Refactoring yang baik jarang terlihat heroik. Ia terlihat seperti tidak terjadi apa-apa — dan itu justru tandanya berhasil.