Kostil dalam pemrograman: apa itu, apa saja jenisnya, dan cara kerjanya

Apa itu kostil dalam pemrograman?

Kostil — adalah istilah slang untuk solusi perangkat lunak yang secara fungsional benar, tetapi secara teknis tidak optimal. Kode semacam itu berfungsi, lolos pengujian, dan bahkan masuk ke produksi, tetapi membacanya menimbulkan keinginan untuk menulis ulang semuanya dari awal. Di lingkungan berbahasa Inggris, istilah workaround, kludge (kluge), hack, atau quick-and-dirty fix digunakan.

Istilah ini berasal dari metafora sehari-hari: jika kaki kursi patah, dapat diikat dengan selotip — kursi kembali berdiri, tetapi solusinya bersifat sementara dan tidak sedap dipandang. Dalam pemrograman sama halnya: bug diperbaiki dengan hardcode, kostil timeout, atau jalan memutar melalui API yang tidak terdokumentasi. Kode dikompilasi, aplikasi tidak crash, tetapi solusinya tidak bisa disebut berkualitas.

Perbedaan penting: bug — saat kode tidak berfungsi, kostil — saat kode berfungsi tetapi dirancang dengan buruk. Kostil selalu merupakan pilihan sadar pengembang: “Saya tahu ini tidak indah, tetapi saat ini ini menyelesaikan masalah”.

Menurut perkiraan Stripe (2024), pengembang menghabiskan rata-rata 17 jam per minggu bekerja dengan utang teknis dan kostil — hampir setengah dari waktu kerja. Ini adalah hilangnya produktivitas tim secara langsung.

Kapan dan mengapa kostil muncul

Penyebab pertama dan utama — tenggat waktu (deadline). Ketika tersisa satu hari menuju rilis dan bug kritis belum diperbaiki, tim memilih solusi cepat daripada solusi yang benar. Hardcode nilai, menonaktifkan pemeriksaan, menambahkan sleep() — contoh klasik kostil deadline. Pengembang berpengalaman selalu menandai tempat-tempat seperti itu dengan TODO atau FIXME.

Penyebab kedua — ketidakcocokan API. Pustaka eksternal atau framework berperilaku berbeda dari yang dijelaskan dalam dokumentasi. Framework tidak mengekspor kelas yang diperlukan, metode ditandai sebagai deprecated, dan tidak ada alternatif. Pengembang terpaksa menggunakan refleksi, API internal, atau jalan memutar. Di Java, ini bisa berupa akses melalui setAccessible(true), di Swift — @objc dan performSelector.

Penyebab ketiga — kode legacy. Pengembang mewarisi proyek yang ditulis 5–10 tahun lalu pada versi framework yang usang. Tidak ada waktu dan anggaran untuk menulis ulang seluruh modul, sehingga fungsionalitas baru “ditempelkan” ke kode lama melalui kostil. Lambat laun, lapisan-lapisan ini menjadi sangat banyak sehingga modul berubah menjadi „big ball of mud”.

Penyebab keempat — kurangnya pengujian. Refactoring tanpa pengujian berbahaya: perubahan arsitektur dapat merusak fungsionalitas yang berfungsi. Ketika tidak ada pengujian, pengembang lebih memilih menambahkan kostil di atas kode yang berfungsi daripada mengambil risiko stabilitas. Menurut Google Testing Blog (2024), tim tanpa pengujian menggunakan solusi workaround 3 kali lebih sering.

Jenis-jenis kostil

Klasifikasi kostil membantu tim memahami jenis utang teknis yang dihadapi dan memilih strategi penghapusan yang tepat. Mari kita lihat jenis-jenis utamanya.

Hardcode — jenis yang paling umum. Alih-alih konfigurasi, sumber daya, atau parameter, nilai tetap dalam kode digunakan. Contoh: URL server yang di-hardcode, timeout 5 detik, ukuran font 16pt. Hardcode membuat kode tidak dapat diskalakan dan memerlukan kompilasi ulang pada setiap perubahan.

Copy-paste — duplikasi fragmen kode dengan perubahan kecil alih-alih mengekstrak logika umum. Gejala klasik: dalam proyek terdapat 3 metode serupa yang berbeda dalam satu baris. Copy-paste mempercepat penulisan kode pada saat tugas, tetapi memperlambat pemeliharaan di masa depan hingga 10 kali lipat — koreksi harus dilakukan di 3 tempat, bukan satu.

Try-catch kosong — blok catch yang tidak melakukan apa pun atau hanya mencatat kesalahan tanpa penanganan. Kostil semacam itu “meredam” pengecualian, tetapi tidak menyelesaikan penyebabnya. Aplikasi terus berfungsi, tetapi data dapat rusak dan pengguna mungkin tidak mendapatkan umpan balik.

Sleep dalam kode — Thread.sleep(500) atau DispatchQueue.main.asyncAfter untuk menunggu ketika seharusnya ada event atau callback. Kode semacam itu tidak dapat diandalkan: pada perangkat lambat, 500 ms mungkin tidak cukup, pada perangkat cepat, jeda akan berlebihan. Gunakan CountDownLatch, Semaphore, atau async/await dengan timing yang tepat.

Bendera kompatibilitas — kaskade if-else yang memeriksa versi OS, model perangkat, atau keberadaan fitur. Ketika bendera lebih dari 3–4, kode berubah menjadi spaghetti. Solusi — Strategy pattern atau Feature Flags melalui konfigurasi.

Kostil vs utang teknis

Banyak pengembang bingung membedakan kostil dan utang teknis. Perbedaannya terletak pada skala dan kesadaran. Kostil — adalah solusi lokal dan konkret (satu metode, satu kelas). Utang teknis — adalah masalah sistemik yang memengaruhi arsitektur modul atau seluruh aplikasi.

Metafora Ward Cunningham (pencipta istilah Technical Debt): utang teknis seperti mengambil pinjaman di bank. Anda mengambil uang sekarang untuk membangun rumah lebih cepat, tetapi kemudian membayar bunga. Kostil — seperti memalu paku dengan palu alih-alih obeng: pekerjaan selesai, tetapi kurang efisien.

Satu kostil tidak menciptakan utang teknis. Tetapi 50 kostil dalam satu modul = utang arsitektur. Oleh karena itu aturan tim: setiap kostil dicatat dalam code review atau task tracker, dan tim secara teratur (sekali per sprint) meninjau akumulasi solusi workaround.

Menurut pengalaman Spotify Engineering (2023), tim yang mencatat kostil dalam kode (melalui label TODO khusus atau custom annotation) mengurangi waktu refactoring sebesar 30% — karena tidak menghabiskan waktu berjam-jam mencari tempat-tempat bermasalah.

Cara menghilangkan kostil

Langkah pertama — inventarisasi. Cari di basis kode kata kunci: TODO, FIXME, HACK, WORKAROUND, KLUDGE. IDE modern menyorotnya dengan warna terpisah. GitHub juga menampilkan TODO di antarmuka Pull Request. Buat daftar semua kostil dengan prioritas.

Langkah kedua — prioritas. Tidak semua kostil perlu segera diperbaiki. Prioritas = frekuensi perubahan dalam file × kekritisan. Jika file berubah 2 kali setahun, kostil bisa menunggu. Jika modul diubah di setiap sprint — kostil harus diperbaiki terlebih dahulu.

Langkah ketiga — refactoring dengan pengujian. Jangan pernah refactor kostil tanpa pengujian. Tulis dulu pengujian yang memeriksa perilaku saat ini (dengan kostil), lalu refactor, lalu pastikan pengujian berhasil. Tanpa ini, refactoring kostil dapat merusak fungsionalitas yang menjadi tujuan penulisannya.

// Sebelum: workaround URL hardcode
fun getApiUrl(): String {
    return "https://api.example.com/v2"
}

// Sesudah: konfigurasi melalui BuildConfig
fun getApiUrl(): String {
    return BuildConfig.API_BASE_URL
}

Langkah keempat — otomatisasi. Konfigurasikan linter yang melarang pola-pola kostil tertentu. Misalnya, Detekt untuk Kotlin dapat memeriksa ketiadaan Thread.sleep() dalam kode produksi, ESLint — melarang console.log dalam proyek. Ini mencegah munculnya kostil baru dengan jenis yang sama.

Kapan kostil dibenarkan

Meskipun konotasi istilahnya negatif, kostil bisa menjadi solusi yang dibenarkan. Syarat utama: kostil bersifat sementara, ditandai secara eksplisit, dan memiliki rencana penggantian. Dalam kode produksi setiap proyek besar terdapat ratusan kostil yang dibenarkan.

Situasi 1: hotfix di produksi. Bug kritis terjadi pada semua pengguna. Tim membutuhkan perbaikan dalam waktu satu jam. Pendekatan yang benar: perbaiki bug dengan cara apa pun, deploy hotfix. Keesokan harinya, tulis solusi yang benar dan tutup tugas. Hotfix adalah kostil yang dibenarkan jika hidup tidak lebih dari 48 jam.

Situasi 2: menunggu rilis versi baru pustaka. Framework berisi bug yang telah diperbaiki di master, tetapi rilis akan keluar dalam 2 minggu. Alih-alih menulis kode jalan memutar yang rumit, tim menambahkan workaround dengan catatan “REMOVE after library 3.2”. Ketika 3.2 rilis, workaround dihapus.

Situasi 3: peluncuran startup atau MVP. Pada tahap MVP, kecepatan lebih penting daripada arsitektur. Kostil di awal adalah hal yang normal. Masalah muncul ketika startup tidak berubah menjadi produk dan kostil tetap ada. Rekomendasi: setelah putaran pendanaan, alokasikan sprint untuk melunasi utang teknis kritis.

Prinsip utama: “Legacy adalah kode orang lain tanpa pengujian” (Michael Feathers). Jika kostil tercakup oleh pengujian dan didokumentasikan secara eksplisit — ia dapat dikelola. Jika tergantung tanpa komentar selama 2 tahun di modul yang terlupakan — itu bukan lagi kostil, melainkan masalah arsitektur.