Tongkat dalam pemrograman — apa itu, penyebab dan kapan dibenarkan

Apa itu “tongkat” dalam pemrograman

Tongkat (crutch) — solusi perangkat lunak yang berfungsi, tetapi dibuat “terburu-buru”: menutup masalah tertentu, tetapi tidak menghilangkan penyebabnya, tidak mengikuti arsitektur proyek, dan dapat rusak pada perubahan lingkungan sekecil apa pun. Metaforanya tepat — seperti tongkat asli, kode semacam itu membantu “berjalan” tetapi tidak menyembuhkan “kaki”.

Pengembang “menopang dengan tongkat” bug, ketidakcocokan versi, fitur platform, dan permintaan mendesak klien. Tongkat tipikal — tongkat-kondisi: jika iOS 15 tambahkan spasi, jika Huawei — sembunyikan tombol. Pemeriksaan semacam itu berlipat ganda dan mengubah kode menjadi “kue berlapis” dari percabangan platform dan versi.

Tongkat bisa berbagai skala: dari satu baris dengan kondisi tongkat hingga seluruh modul perantara yang “memperbaiki” perilaku pustaka. Penting dipahami bahwa tongkat tidak selalu buruk: di tangan yang tepat, ini adalah alat yang memungkinkan merilis produk tepat waktu. Masalah dimulai ketika tongkat tetap di kode selamanya.

Mengapa tongkat muncul: penyebab dan konteks

Penyebab utama munculnya tongkat adalah konflik antara solusi ideal dan batasan nyata proyek. Pengembang tahu cara melakukannya dengan benar, tetapi waktu, uang, atau batasan teknis tidak memungkinkan. Hasilnya adalah solusi kompromi yang “hanya bekerja”.

Mari kita lihat empat penyebab utama mengapa pengembang secara sadar menggunakan tongkat. Memahami penyebab ini membantu memandang tongkat bukan sebagai kesalahan, tetapi sebagai alat pragmatis yang memerlukan pengelolaan.

Tenggat waktu

Penyebab paling umum. Rilis besok, bug hanya muncul di model tertentu, perbaikan arsitektur memakan waktu dua minggu. Tongkat-kondisi memakan waktu satu jam dan menutup masalah. Setelah rilis, tim berjanji untuk kembali dan menulis ulang dengan benar. “Tidak ada yang lebih permanen daripada solusi sementara” — tepatnya tentang tongkat semacam ini.

Ketidakcocokan versi

Pustaka A membutuhkan Android 12, tetapi aplikasi Anda mendukung Android 10. Solusinya — menulis lapisan perantara yang memeriksa versi OS dan memilih jalur eksekusi. Ini adalah tongkat, karena saat memperbarui pustaka, lapisan perantara harus ditulis ulang. Namun alternatif — meninggalkan pustaka atau dukungan perangkat lama — bisa lebih buruk.

// Tongkat untuk kompatibilitas API 29
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
    useModernApi()
} else {
    useLegacyFallback()
}

Ketergantungan eksternal dengan bug

Pustaka yang menjadi ketergantungan proyek mengandung bug, tetapi pembaruannya bisa memakan waktu berminggu-minggu (perlu PR, tinjauan kode, publikasi). Alih-alih menunggu, tim menulis wrapper yang menambal perilaku pustaka dengan cepat. Setelah versi pustaka yang diperbaiki dirilis, wrapper dihapus. Jika tidak dihapus — itu sudah menjadi masalah arsitektur.

Pemahaman sistem yang tidak lengkap

Pengembang baru di proyek legacy tidak mengerti mengapa kode bekerja persis seperti itu. Alih-alih memahaminya, ia menambahkan kondisi baru di atas kondisi yang sudah ada. Ini adalah jenis tongkat paling berbahaya, karena penulis tidak menyadari bahwa ini adalah tongkat. Satu-satunya obat — tinjauan kode dan pemrograman berpasangan untuk anggota tim baru.

Kapan tongkat dibenarkan: pendekatan pragmatis

Tidak setiap tongkat itu buruk. Dalam pengembangan nyata, kemurnian kode absolut tidak dapat dicapai dan seringkali tidak tepat. Pendekatan pragmatis mengakui bahwa solusi sementara adalah bagian dari proses, tetapi memerlukan kesadaran, dokumentasi, dan perencanaan penghapusan. Tongkat dibenarkan ketika menyelesaikan tugas bisnis lebih cepat daripada solusi arsitektur murni.

Kriteria tongkat yang dibenarkan: menutup masalah tertentu, memiliki pemilik (siapa yang bertanggung jawab atas penghapusannya), dan ada rencana refaktorisasi. Jika setidaknya satu dari tiga kondisi tidak terpenuhi — tongkat berubah menjadi utang teknis. Alat seperti komentar TODO dengan tiket di pelacak — cara dokumentasi minimal.

Contoh tongkat yang dibenarkan

Bug kritis di cabang rilis yang harus ditutup sebelum penerapan besok. Solusi murni memerlukan refaktorisasi arsitektur dan akan memakan waktu dua minggu. Tongkat — tambahkan pemeriksaan nil dan kirim perbaikan sebagai hotfix. Syarat pembenaran: tiket untuk refaktorisasi dibuat di pelacak, penanggung jawab ditunjuk, tongkat ditandai dengan komentar. Dua minggu kemudian tim kembali ke tugas.

// TODO: IT-1234 — hapus tongkat ini setelah refaktorisasi AuthService
guard let userId = session.user?.id else {
    return Result.failure(.notAuthenticated)
}

Bagaimana membedakan tongkat sementara dari masalah arsitektur

Batas antara tongkat sadar dan masalah arsitektur (utang teknis) melewati dua parameter: kesadaran keputusan dan adanya rencana penghapusan. Tongkat selalu merupakan solusi sementara dengan masa hidup yang diketahui. Utang teknis — konsekuensi dari banyak tongkat yang ditinggalkan tanpa perhatian.

Kapan tongkat menjadi masalah

Situasi memburuk ketika jumlah tongkat melebihi massa kritis. Setiap tongkat baru meningkatkan “kerapuhan” sistem: perubahan di satu tempat merusak yang lain. Akibatnya, pengembangan melambat, bug berlipat ganda, dan pengembang baru tidak dapat memahami kode tanpa bantuan penulis. Pada saat ini, tongkat berhenti menjadi solusi sementara dan menjadi masalah arsitektur.

Tanda-tanda krisis tongkat

Jika dalam kode terdapat lima pemeriksaan bersarang untuk versi OS, produsen perangkat, dan keberadaan pustaka tertentu — ini bukan tongkat, ini masalah arsitektur. Jika penambahan satu perbaikan menyebabkan tiga regresi di modul tetangga — tongkat tidak lagi lokal. Jika tinjauan kode secara teratur ditolak karena “tongkat lagi” — saatnya merencanakan refaktorisasi.

• Tongkat yang sama berulang di tiga tempat atau lebih — saatnya solusi seragam
• Tongkat hidup lebih dari tiga sprint tanpa rencana penghapusan — ini sudah utang teknis
• Pengembang baru tidak mengerti mengapa kode bekerja seperti ini — tongkat tidak didokumentasikan
• Penghapusan tongkat menyebabkan reaksi berantai kesalahan — ketergantungan pada tongkat telah menjadi arsitektur

Refaktorisasi tongkat: strategi dan praktik

Refaktorisasi tongkat — proses mengganti solusi sementara dengan yang benar secara arsitektur. Ini membutuhkan waktu, oleh karena itu diperlukan strategi prioritas: tidak semua tongkat perlu segera dihilangkan. Strategi yang baik — menilai setiap tongkat berdasarkan dua parameter: frekuensi perubahan di area kode tersebut dan dampak pada pengguna.

Strategi prioritas

Prioritas tinggi — tongkat di modul yang sering diubah (logika bisnis, UI tujuan umum) yang memperlambat pengembangan dan menyebabkan regresi. Prioritas sedang — tongkat di modul yang jarang diubah, tetapi dengan potensi dampak pada pengguna (pemrosesan pembayaran, otorisasi). Prioritas rendah — tongkat di kode legacy yang bekerja stabil dan tidak direncanakan untuk dimodifikasi.

Proses penghapusan langkah demi langkah

Langkah 1: inventarisasi — temukan semua TODO dan FIXME terkait tongkat. Langkah 2: evaluasi — tentukan mana yang masih relevan. Langkah 3: perencanaan — jadwalkan refaktorisasi tongkat dalam sprint, mulai dari prioritas tinggi. Langkah 4: penggantian — implementasikan solusi murni, hapus tongkat dan komentar TODO-nya. Langkah 5: verifikasi — pastikan tes lulus dan tidak ada regresi.

# Temukan semua TODO-tongkat di proyek
grep -r "TODO\|FIXME\|HACK\|XXX" --include="*.kt" --include="*.swift" .

Mencegah tongkat baru

Cara terbaik melawan tongkat adalah tidak membuatnya tanpa kebutuhan. Sebelum menulis tongkat, tanyakan pada diri sendiri tiga pertanyaan: dapatkah solusi murni dibuat dalam waktu yang wajar? Apakah ada alternatif yang bukan tongkat? Akankah tim punya waktu untuk kembali dan menulis ulang ini? Jika setidaknya satu pertanyaan dijawab “tidak” — pikirkan lagi sebelum “menopang” kode.