Junk dalam pengembangan — apa itu, mengapa junk-code berbahaya dan cara menghapusnya

Apa itu junk?

Junk (junk code) — istilah kolektif untuk kode, konfigurasi, dan ketergantungan yang ada dalam proyek tetapi tidak memiliki nilai fungsional. Junk belum tentu rusak atau tidak digunakan — masalahnya adalah keberadaannya memperburuk metrik proyek tanpa pembenaran yang memadai.

Junk dibagi menjadi empat kategori. Pertama — ketergantungan berlebihan: pustaka yang ditambahkan untuk satu fungsi yang dapat diimplementasikan dengan alat standar. Kedua — beban mati: blok yang dikomentari, TODO tanpa tiket, metode kosong, dan kelas stub. Ketiga — solusi duplikat: dua pustaka yang melakukan hal yang sama (misalnya, Gson dan Kotlin Serialization dalam satu proyek). Keempat — over-engineering: lapisan arsitektur yang tidak digunakan tetapi dipelihara „untuk masa depan”.

Menurut penelitian Stripe Engineering Productivity (2025), menghapus 10 persen junk dari proyek tipikal mengurangi waktu pembangunan penuh rata-rata 22 persen. Alasannya: setiap ketergantungan tambahan memperbesar grafik pembangunan, setiap abstraksi kosong membutuhkan waktu untuk dipahami, setiap blok yang dikomentari mengalihkan perhatian.

Kesulitan utama dalam memerangi junk adalah tidak adanya konsekuensi langsung. Proyek dengan junk-code tetap dikompilasi dan berfungsi. Masalah menumpuk secara bertahap: pembangunan melambat, jumlah ketergantungan transitif bertambah, dan setelah satu tahun menambahkan fitur baru memakan waktu dua kali lebih lama dari seharusnya.

Ketergantungan junk dan cara mengidentifikasinya

Ketergantungan junk — adalah pustaka dan paket yang terhubung ke proyek tetapi tidak digunakan secara langsung dalam kode, atau hanya digunakan dalam satu fungsi yang lebih mudah diimplementasikan dengan API standar.

Contoh tipikal: pustaka untuk bekerja dengan JSON ketika proyek sudah menggunakan Kotlin Serialization (dua parser — itu junk); pustaka Apache Commons Lang untuk satu metode StringUtils.isEmpty, yang dapat diganti dengan ekstensi Kotlin isNullOrBlank; pustaka DI yang digunakan dalam satu dari sepuluh modul, sementara yang lainnya mendapatkan ketergantungan secara manual melalui konstruktor.

Setiap ketergantungan tambahan bukan hanya kode ekstra dalam biner. Ini juga meningkatkan permukaan serangan untuk kerentanan: menurut GitHub Advisory Database (2025), 40 persen CVE kritis dalam proyek seluler berasal dari ketergantungan transitif yang tidak dikendalikan oleh pengembang. Semakin sedikit ketergantungan — semakin kecil permukaan serangan.

Analisis ketergantungan proyek Android

// Lihat pohon ketergantungan Gradle
./gradlew app:dependencies --configuration releaseRuntimeClasspath

// Temukan ketergantungan tidak digunakan (plugin Gradle)
plugins {
    id "com.autonomousapps.dependency-analysis" version "2.0.0"
}

// Hasilkan laporan pustaka tidak digunakan
./gradlew buildHealth

Untuk iOS gunakan perintah swift package show-dependencies, yang menampilkan pohon ketergantungan lengkap. Alat Xcode Build Timeline menunjukkan berapa banyak waktu yang ditambahkan setiap pustaka ke pembangunan. Jika pustaka memakan 30 persen waktu kompilasi tetapi hanya digunakan di satu layar — itu adalah kandidat untuk dihapus atau diganti.

Untuk Node.js (React Native) gunakan depcheck — utilitas yang menemukan ketergantungan tidak digunakan di package.json, dan npm-check, yang juga menunjukkan versi usang. Terapkan aturan: setiap ketergantungan baru harus melewati code review dengan justifikasi „mengapa tidak bisa dengan alat standar”.

Impor mati dan kode yang dikomentari

Impor mati — jenis junk yang paling umum. Mereka tidak mempengaruhi runtime, tetapi meningkatkan waktu kompilasi: kompiler memproses setiap impor, bahkan jika tidak digunakan. Dalam proyek besar, menghapus impor yang tidak digunakan mengurangi waktu pembangunan sebesar 5–10 persen.

IDE modern secara otomatis menyorot impor yang tidak digunakan dengan warna abu-abu. Konfigurasikan pembersihan otomatis saat menyimpan file: di IntelliJ IDEA — Optimize Imports on the fly, di Xcode — Editor > Remove Unused Imports. Di CI tambahkan pemeriksaan: linter harus memblokir commit dengan impor yang tidak digunakan.

Kode yang dikomentari — jenis junk lainnya. Pengembang memberi komentar pada blok agar tidak kehilangan fungsionalitas saat refactoring. Namun git menyimpan riwayat lengkap perubahan: kode yang dihapus dapat dipulihkan dengan satu perintah git revert atau git log -S . Kode yang dikomentari di master adalah tidak hormat kepada tim: setiap pengembang menghabiskan energi mental untuk bertanya „mengapa ini dikomentari dan kapan harus dibuka komentarnya”.

Aturan: tidak ada kode yang dikomentari di repositori. Jika kode tidak diperlukan — hapus selamanya. Jika kode diperlukan tetapi dinonaktifkan sementara — gunakan feature toggle dengan tiket dan tenggat waktu. Komentar seperti // TODO: remove after migration — jangan tinggalkan tanpa tenggat. Beri tanggal dan atur pengingat di kalender.

Abstraksi berlebihan dan over-engineering

Over-engineering — menciptakan lapisan arsitektur yang tidak menyelesaikan masalah saat ini tetapi membutuhkan pemeliharaan. Ini adalah salah satu jenis junk yang paling sulit karena secara formal kodenya „benar”: mematuhi SOLID, dilindungi pengujian, dan sesuai dengan arsitektur. Masalahnya adalah tidak diperlukan.

Contoh klasik — kelas abstrak UseCase dengan satu metode invoke yang hanya memanggil repositori. Jika UseCase tidak menambahkan logika (caching, retry, transformasi), hanya meneruskan panggilan — itu adalah entitas berlebihan. Ini meningkatkan navigasi melalui proyek: pengembang membuka UseCase, melihat invoke → repository — dan menutupnya. Waktu terbuang, manfaat nol.

Contoh lain — parameterisasi berlebihan. Antarmuka generik dengan enam parameter tipe, digunakan di satu tempat. Setiap parameter tipe adalah beban kognitif: saat membaca kode, Anda harus mengingat enam tipe, padahal hanya dua yang benar-benar digunakan. Jika abstraksi tidak digunakan kembali — itu berlebihan.

Kriteria pemotongan: jika abstraksi tidak digunakan kembali dalam tiga konteks berbeda — hapus. Abstraksi dibenarkan ketika benar-benar memecahkan masalah duplikasi, bukan ketika memprediksi skenario masa depan hipotetis. YAGNI (You Ain't Gonna Need It) — prinsip terbaik pencegahan over-engineering.

Alat audit junk

Audit junk memerlukan kombinasi analisis statis, analisis ketergantungan, dan pemeriksaan manual. Pencarian abstraksi berlebihan tidak dapat sepenuhnya diotomatisasi, tetapi junk teknis (impor mati, pustaka tidak digunakan, kode yang dikomentari) dapat ditemukan dengan alat.

Untuk audit lengkap, jalankan buildHealth (Android) atau depcheck (Node.js) sekali per sprint. Buat dashboard di CI yang menunjukkan dinamika jumlah ketergantungan dari sprint ke sprint. Jika jumlahnya meningkat tetapi fungsionalitas tidak meningkat secara proporsional — tim sedang menumpuk junk.

Perhatikan duplicate classes — kesalahan ketika dua pustaka berisi kelas yang sama. Ini bukan hanya junk, tetapi juga sumber langsung konflik pembangunan. Di Gradle, konflik semacam itu diselesaikan melalui force atau exclude, tetapi setiap penyelesaian semacam itu adalah sinyal bahwa salah satu pustaka berlebihan.

Proses pembersihan proyek secara teratur

Membersihkan junk bukanlah tindakan satu kali, melainkan proses teratur. Tanpa aturan, junk kembali dalam dua hingga tiga sprint. Praktik terbaik — alokasikan 10–15 persen kapasitas setiap sprint untuk pembersihan teknis, termasuk audit junk.

Prosesnya terdiri dari empat langkah. Pertama — diagnostik: menjalankan alat, mendapatkan laporan, memprioritaskan. Prioritas tinggi — ketergantungan dengan CVE yang diketahui dan pustaka duplikat. Sedang — impor mati dan kode yang dikomentari. Rendah — abstraksi berlebihan (memerlukan analisis manual).

Kedua — pembersihan: menghapus ketergantungan mati, mengganti pustaka duplikat dengan satu, menghapus kode yang dikomentari. Setiap perubahan dibuat dalam commit terpisah dengan pesan yang jelas: „remove unused dependency: gson (replaced by kotlinx.serialization)”, „delete commented code in LoginViewModel”.

Ketiga — verifikasi: membangun proyek, menjalankan pengujian, memeriksa UI. Jika setelah menghapus ketergantungan pengujian lulus — ketergantungan memang tidak diperlukan. Jika pengujian gagal — berarti ada referensi tersembunyi yang tidak terdeteksi oleh penganalisis statis.

Keempat — pencegahan: memperbarui daftar periksa code review, menambahkan aturan „tidak ada ketergantungan baru tanpa justifikasi” ke Definition of Done, mengatur pemeriksaan otomatis di CI. Pencegahan adalah satu-satunya cara untuk mencegah penumpukan junk berulang.