Kode mati dan kode zombie dalam pengembangan: apa itu, penyebab dan pencarian

Apa itu kode mati?

Kode mati (dead code) — kode sumber yang disertakan dalam program, tetapi tidak pernah dijalankan dalam skenario penggunaan apa pun. Kompiler atau penerjemah memprosesnya, tetapi saat runtime, kontrol tidak pernah masuk ke bagian-bagian ini.

Contoh klasik kode mati: variabel yang diberi nilai tetapi tidak pernah dibaca; fungsi atau metode yang tidak pernah dipanggil di mana pun; cabang kondisi yang tidak pernah menjadi benar (if(false)); perulangan yang tubuhnya tidak pernah dijalankan satu kali pun.

Menurut laporan SonarQube State of Code Quality (2025), sekitar 15 persen dari semua peringatan di proyek Java komersial terkait dengan metode dan bidang private yang tidak digunakan. Dalam proyek JavaScript, proporsi kode yang tidak digunakan dapat mencapai 30 persen karena sifat dinamis bahasa dan banyaknya pustaka pihak ketiga.

Periksa proyek secara teratur untuk kode mati — terutama setelah refactoring besar dan penghapusan fitur. Satu import yang terlupakan atau fungsi yang tidak digunakan hari ini besok dapat berubah menjadi kode zombie yang menyesatkan anggota tim baru.

Perbedaan antara kode mati dan kode zombie

Kode zombie (zombie code) — kasus khusus kode mati yang dibedakan oleh konteks historis. Kode zombie dulu berfungsi, tetapi setelah perubahan dalam sistem menjadi tidak dapat dijangkau, meskipun tidak dihapus, melainkan ditinggalkan “untuk jaga-jaga”.

Perbedaan antara kode mati dan kode zombie terletak pada asalnya. Kode mati mungkin ditulis secara tidak sengaja (tidak pernah berfungsi), sedangkan kode zombie adalah kode yang dulunya hidup dan kehilangan relevansi selama refactoring. Misalnya, fungsi perhitungan diskon berdasarkan logika bisnis lama yang digantikan dengan yang baru, tetapi metode lamanya tidak dihapus — untuk berjaga-jaga jika perlu dikembalikan.

Bahaya utama kode zombie adalah ilusi fungsionalitas yang berfungsi. Pengembang baru melihat fungsi, membaca dokumentasinya, mengira bahwa fungsi itu dipanggil di suatu tempat — dan membuang waktu mempelajari artefak. Saat mencoba memanggilnya secara langsung, mungkin ternyata itu bergantung pada entitas yang dihapus atau API yang usang.

Lacak kode zombie melalui riwayat git: jika suatu fungsi tidak berubah selama dua tahun dan tidak digunakan — itu zombie. Hapus tanpa ragu, karena git menyimpan riwayat dan jika perlu, kode selalu dapat dipulihkan.

Penyebab munculnya kode mati

Penyebab pertama dan paling umum — pengembangan iteratif dengan refactoring tidak lengkap. Tim menambahkan fungsionalitas baru yang menggantikan yang lama, tetapi tidak menghapus modul yang digantikan. Sprint mengumpulkan “ekor” seperti itu dan setelah satu tahun proyek tertutup lapisan kode mati.

Penyebab kedua — pengujian A/B dan feature toggle. Kondisi untuk mengaktifkan fitur baru dapat menjadi tetap seiring waktu (misalnya, selalu true), tetapi cabang else dengan logika alternatif tetap ada di kode. Pengembang takut menghapusnya agar tidak secara tidak sengaja merusak sistem jika toggle dialihkan kembali.

Penyebab ketiga — pembuatan otomatis dan copy-paste. Generator kode (IDE, templat) membuat kerangka dengan metode yang tidak diisi atau tidak digunakan oleh pengembang. Kode yang disalin dari proyek lain sering berisi seluruh blok yang tidak relevan dengan konteks baru.

Penyebab keempat — takut menghapus. Dalam proyek besar, pengembang takut menghapus kode karena tidak yakin bahwa kode tersebut benar-benar tidak digunakan di mana pun. Ketakutan ini diperparah oleh sistem pengujian yang lemah: jika tidak ada pemeriksaan otomatis, penghapusan dapat menyebabkan bug yang baru ditemukan di produksi.

Mengapa kode mati berbahaya

Kode mati secara langsung memengaruhi empat aspek kualitas proyek: kinerja kompilasi, ukuran artefak, beban kognitif tim, dan keandalan refactoring.

Peningkatan waktu kompilasi: kompiler memproses file yang tidak digunakan, menganalisis dependensi, dan menghasilkan kode bita atau kode mesin untuk fragmen yang tidak akan pernah dijalankan. Dalam proyek besar, ini menambahkan menit ke setiap kompilasi. Untuk bahasa yang diinterpretasi (JavaScript, Python), waktu pemuatan modul dan konsumsi memori meningkat.

Risiko bug saat modifikasi: pengembang, saat mengubah kode, tidak curiga bahwa fungsi tersebut hanya digunakan di cabang mati. Setelah refactoring, kode mati berhenti dikompilasi atau menghasilkan kesalahan — tim membuang waktu untuk mendiagnosis masalah yang tidak memengaruhi pengoperasian aplikasi.

Beban kognitif — faktor yang paling mahal. Setiap fungsi yang tidak digunakan memerlukan perhatian saat membaca kode. Pengembang menghabiskan energi mental untuk memahami mengapa kode ini ada dan di mana dipanggil. Penelitian Developer Productivity Lab (2025) menunjukkan: menghapus 20 persen kode mati mengurangi waktu orientasi (onboarding time) rata-rata sebesar 18 persen.

Hapus kode mati segera setelah terdeteksi. Setiap hari penundaan meningkatkan kemungkinan seseorang dari tim menghabiskan berjam-jam mempelajari artefak yang seharusnya sudah dihapus kemarin.

Alat pencarian kode mati

Pencarian kode mati dilakukan dengan dua metode utama: analisis statis (tanpa menjalankan program) dan analisis dinamis (profil cakupan saat runtime). Setiap pendekatan efektif untuk berbagai jenis kode mati.

Analisator statis mendukung semua bahasa pemrograman populer. Untuk Java dan Kotlin — SonarQube, IntelliJ IDEA Inspections, SpotBugs. Untuk JavaScript dan TypeScript — ESLint dengan aturan no-unused-vars dan no-unused-modules. Untuk Swift — SwiftLint dengan aturan unused_declaration. Untuk Python — pylint dengan opsi unused-import dan vulture untuk pencarian mendalam.

Contoh pencarian di Kotlin melalui ProGuard

// build.gradle.kts — konfigurasi ProGuard untuk Android
android {
    buildTypes {
        release {
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
}

// proguard-rules.pro — simpan hanya kelas yang diperlukan
-keep class com.example.app.** { *; }
-assumenosideeffects class Timber {
    static <methods>;
}

ProGuard tidak hanya menghapus kelas dan metode yang tidak digunakan, tetapi juga mengecilkan nama dalam kompilasi release. Kompilasi dengan ProGuard diaktifkan secara otomatis menunjukkan kelas dan metode mana yang dianggap tidak digunakan — dalam laporan usage.txt semua kode yang dihapus terdaftar.

Analisis dinamis melalui cakupan tes

Alat cakupan kode (JaCoCo untuk Java, XCTest coverage untuk Swift, Istanbul untuk JavaScript) menunjukkan baris dan cabang mana yang dijalankan selama pengujian. Metode dengan cakupan nol adalah kandidat kode mati. Namun, tidak adanya cakupan tidak menjamin bahwa kode tidak dipanggil di produksi — untuk kepastian penuh, gunakan kombinasi analisis statis dan dinamis.

Konfigurasikan pipeline CI sehingga kompilasi gagal ketika ambang deklarasi yang tidak digunakan terlampaui. SonarQube Quality Gate dengan aturan “Proporsi kode private yang tidak digunakan tidak lebih dari 3%” mencegah akumulasi kode mati di tingkat proses pengembangan.

Cara menghapus kode mati dengan aman

Proses penghapusan kode mati terdiri dari empat langkah: temukan, periksa, hapus, periksa lagi. Melewatkan langkah apa pun meningkatkan risiko regresi.

Langkah pertama — cari kandidat melalui penganalisis statis. Dapatkan laporan tentang deklarasi yang tidak digunakan: fungsi, kelas, variabel, impor. Filter positif palsu — penganalisis terkadang salah saat refleksi, pemuatan kelas dinamis, atau panggilan tersembunyi melalui serialisasi.

Langkah kedua — periksa melalui git blame dan riwayat perubahan. Lihat kapan dan mengapa kode ditulis. Jika kode adalah bagian dari fitur yang dinonaktifkan oleh feature toggle, pastikan toggle sudah tetap dan tidak akan diaktifkan kembali. Komentari kode yang Anda ragukan untuk dihapus dan tinggalkan TODO dengan tiket untuk pemeriksaan ulang dalam sebulan.

Langkah ketiga — hapus di cabang terpisah dengan menjalankan rangkaian pengujian lengkap. Jika pengujian lulus — kemungkinan regresi rendah. Jika pengujian gagal — berarti kode masih digunakan dan perlu ditentukan dalam skenario apa.

// sebelum — kode mati dan kode zombie di file yang sama
int calculateV1(int price) { // tidak dipanggil di mana pun
    int tax = price * 0.18;
    return price + tax;
}

int calculateV2(int price, double rate) {
    return static_cast<int>(price * (1 + rate));
}

// setelah — kode mati dihapus, kode zombie dibersihkan
int calculatePrice(int price, double rate) {
    return static_cast<int>(price * (1 + rate));
}

Langkah keempat — code review perubahan. Peninjau harus mengonfirmasi bahwa kode benar-benar mati. Jika peninjau tidak yakin — tinggalkan komentar di kode dan tunda penghapusan hingga analisis penuh. Setelah cabang digabung, hapus cabang agar tidak memperbanyak kode zombie di repositori git.

Terapkan aturan: tidak ada pull request yang boleh mengandung kode mati baru. Tambahkan linter ke hook pre-commit yang memblokir commit jika ada variabel atau impor yang tidak digunakan. Pencegahan selalu lebih murah daripada pembersihan.