Tech Debt dan Refactoring
Mengelola hutang teknis secara strategis dan memutuskan kapan harus refactor
Apa itu Tech Debt
- Konsekuensi dari mengambil jalan pintas teknis untuk kecepatan jangka pendek
- Bukan selalu buruk — kadang adalah trade-off yang disadari dan masuk akal
- Menjadi masalah ketika tidak dikelola dan terus menumpuk
- Analogi: hutang finansial — kecil oke, tapi bunga bisa menghancurkan jika dibiarkan
Jenis-jenis Tech Debt
Deliberate (Disengaja)
- Keputusan sadar untuk mengambil jalan pintas demi kecepatan
- Contoh: hardcode konfigurasi untuk MVP, skip validasi untuk prototyping
- Paling mudah dikelola karena terdokumentasi
Inadvertent (Tidak Disengaja)
- Timbul dari kurangnya pengetahuan atau pengalaman saat kode ditulis
- Contoh: arsitektur yang tidak scalable karena tim tidak antisipasi pertumbuhan
- Baru terlihat setelah sistem berkembang
Bit Rot
- Kode yang dulunya baik tapi jadi masalah seiring perubahan konteks
- Contoh: library yang tidak diupdate, pola yang sudah deprecated
- Tumbuh secara pasif tanpa ada keputusan aktif
Biaya Tech Debt
- Developer velocity turun: perubahan kecil butuh waktu lama
- Bug rate meningkat: kode sulit dipahami sehingga mudah salah dimodifikasi
- Onboarding lebih lama: engineer baru sulit memahami sistem
- Motivasi turun: engineer frustrasi bekerja di sistem yang buruk
Mengelola Tech Debt Secara Strategis
Audit dan Kategorisasi
- Kumpulkan semua item debt yang diketahui tim
- Kategorikan berdasarkan dampak: high/medium/low
- Estimasi biaya untuk membiarkan vs memperbaiki
Budget 20%
- Alokasikan sekitar 20% kapasitas sprint untuk membayar debt
- Jangan tunggu "sprinkle debt" menumpuk menjadi proyek besar
- Jadikan debt paydown bagian rutin, bukan event khusus
Debt Register
- Maintain daftar debt yang diketahui dalam bentuk dokumen atau ticket
- Catat konteks: kenapa dibuat, dampaknya, dan estimasi perbaikan
- Review debt register secara berkala (tiap kuartal)
Kapan Refactor vs Rewrite
| Situasi | Keputusan |
|---|---|
| Masalah lokal di satu modul | Refactor bagian tersebut |
| Arsitektur fundamental salah | Pertimbangkan rewrite bertahap |
| Tim tidak ada yang paham kode lama | Rewrite dengan dokumentasi paralel |
| Sistem masih berkembang pesat | Tunda, fokus di area yang stabil |
| Bug terus berulang di area sama | Refactor area tersebut |
Strangler Fig Pattern: cara aman untuk rewrite bertahap — bangun sistem baru di samping sistem lama, pindahkan traffic secara incremental.
Cara Menjual Tech Debt ke Stakeholder
- Hindari bahasa teknis ("refactor", "rewrite") — gunakan bahasa bisnis
- Hubungkan ke dampak nyata: "fitur X butuh 2 minggu karena debt di modul Y, seharusnya 3 hari"
- Frame sebagai investasi, bukan pengeluaran: "6 minggu sekarang menghemat 3 bulan dalam setahun"
- Tunjukkan trend: jika debt tidak dibayar, velocity akan terus turun
Praktik Terbaik
- Jangan akumulasi debt secara diam-diam — komunikasikan ke product dan stakeholder
- Tidak semua debt perlu dibayar — prioritaskan yang paling mempengaruhi velocity atau reliability
- Jadikan refactoring bagian dari Definition of Done untuk fitur baru
- Jangan refactor dan tambah fitur dalam satu PR yang sama