Kode sampah dan kekacauan di proyek mobile — tanda-tanda dan refaktorisasi

Apa itu kode sampah dalam pengembangan

Kode sampah (juga spaghetti code, kekacauan, big ball of mud) — adalah metafora untuk basis kode yang kehilangan struktur dan berubah menjadi kusut dependensi. Dalam kode seperti itu, setiap perubahan di satu tempat merusak tempat lain, dan menambah fungsionalitas baru menjadi tugas berisiko.

Dalam pengembangan mobile kode sampah sangat kritis: aplikasi yang dibangun di atas "kekacauan" mulai melambat, crash di perangkat lama dan sulit melewati code review. Proyek iOS tanpa arsitektur mungkin tidak lolos App Review karena ketidakstabilan.

Menurut data Stripe, pengembang menghabiskan hingga 42% waktu kerja untuk membaca dan memahami kode yang ada. Dalam proyek dengan kode sampah, angka ini melebihi 60%, membuat pengembangan sangat tidak efisien.

Asal-usul istilah

Spaghetti code (kode spageti) — istilah tertua, muncul pada tahun 1970-an. Ini menggambarkan kode dengan lompatan kontrol yang kacau, mengingatkan pada spageti yang kusut.

Big ball of mud (bola lumpur besar) — istilah yang diperkenalkan oleh Brian Foot dan Joseph Yoder pada tahun 1997 untuk menggambarkan sistem tanpa arsitektur jelas yang "tumbuh" secara kacau.

Mengapa kode sampah berbahaya bagi bisnis

Kode sampah memperlambat peluncuran fitur baru ke pasar. Tim menghabiskan waktu bukan untuk menciptakan nilai, tetapi untuk mencoba memahami cara kerja kode yang ada dan tidak merusak apa pun.

Menurut data McKinsey, perusahaan dengan kualitas kode rendah menghabiskan 20-40% lebih banyak untuk pemeliharaan produk, dan kecepatan peluncuran fitur baru 2-3 kali lebih rendah dibandingkan perusahaan dengan kualitas kode tinggi.

Tanda-tanda kode sampah dan cara mengenalinya

Mengenali kode sampah dapat dilakukan melalui serangkaian tanda objektif, beberapa di antaranya diukur secara otomatis. Semakin banyak tanda yang cocok — semakin serius masalahnya.

Dalam industri digunakan metrik kualitas kode seperti Halstead Complexity, Maintainability Index dan Technical Debt Ratio. Pengetahuan tentang metrik ini membantu menilai kondisi basis kode secara objektif.

Copy-paste (duplikasi kode)

Tanda paling umum dari kode sampah — blok kode yang berulang. Alih-alih mengekstrak fungsi bersama, pengembang menyalin kode dari satu tempat ke tempat lain dengan perubahan minimal.

Tingkat normal duplikasi dianggap hingga 5%. Jika duplikasi melebihi 15% — ini sinyal serius. Alat seperti Simian dan PMD Copy Paste Detector membantu mendeteksi copy-paste secara otomatis.

Metode dan kelas panjang

Metode lebih panjang dari 100 baris — tanda jelas kode sampah. Metode seperti itu biasanya melakukan terlalu banyak hal dan melanggar prinsip tanggung jawab tunggal (Single Responsibility).

Kelas dengan lebih dari 1000 baris kode juga bermasalah. Mereka berisi fungsionalitas tidak terkait, yang mempersulit pengujian, pemahaman dan modifikasi kode.

Kompleksitas siklomatis tinggi

Kompleksitas siklomatis McCabe (Cyclomatic Complexity) — metrik yang menunjukkan jumlah jalur independen dalam kode. Nilai di atas 15 dianggap bermasalah.

Metode dengan kompleksitas di atas 30 — "zona bencana". Mereka mengandung terlalu banyak percabangan, tidak dapat diuji atau dipahami tanpa analisis mendalam.

Penyebab munculnya kode sampah

Kode sampah tidak muncul "dengan sendirinya" — selalu merupakan hasil dari proses dan keputusan tertentu dalam tim. Memahami penyebab memungkinkan pencegahan kemunculannya di masa depan.

Menurut data JetBrains Developer Ecosystem 2024, 67% pengembang mengakui bahwa mereka menulis kode lebih buruk dari yang bisa mereka lakukan karena kekurangan waktu. Ini adalah penyebab utama akumulasi utang teknis.

Tergesa-gesa dan tenggat waktu

Penyebab paling umum — tenggat yang ketat. Tim menulis kode "yang penting jadi", asal memenuhi tenggat. Refaktorisasi, tes dan code review ditunda "nanti".

Masalahnya adalah "nanti" tidak pernah tiba — di sprint berikutnya muncul tenggat baru dan utang teknis menumpuk seperti bola salju.

Tidak ada code review

Tanpa code review, setiap pengembang menulis dengan gayanya sendiri, menggunakan pola sendiri dan meninggalkan "jebakan" sendiri. Seiring waktu, basis kode kehilangan keseragaman.

Tim yang mempraktikkan code review wajib untuk setiap pull request memiliki 60% lebih sedikit cacat di produksi, menurut penelitian SmartBear 2024.

Arsitektur lemah dari awal

Jika proyek dimulai tanpa arsitektur yang jelas, kode sampah tidak terhindarkan. "Solusi cepat" pertama meletakkan fondasi di mana kemudian sulit membangun sesuatu yang berkualitas.

Dalam pengembangan mobile, pilihan arsitektur (MVC, MVP, MVVM, Clean Architecture) harus menjadi keputusan sadar yang diambil sebelum mulai menulis kode, bukan hasil evolusi.

Metode melawan kode sampah

Melawan kode sampah membutuhkan pendekatan sistematis dan disiplin seluruh tim. Tidak ada satu alat atau praktik pun yang akan menyelesaikan masalah — diperlukan serangkaian tindakan.

Prinsip utama — jangan biarkan kode sampah pada tahap penulisan, bukan memperbaikinya nanti. Pencegahan selalu lebih murah daripada refaktorisasi "kekacauan" yang sudah ada.

Standar pengkodean

Gaya kode seragam — dasar untuk mencegah kode sampah. Standar pengkodean (Code Style) harus didokumentasikan dan diperiksa secara otomatis oleh linter.

Untuk iOS digunakan SwiftLint, untuk Android — Ktlint dan Detekt. Pengaturan aturan dalam file konfigurasi memungkinkan penolakan otomatis pull request yang melanggar standar.

Refaktorisasi rutin

Refaktorisasi — bukan memperbaiki bug, tetapi meningkatkan struktur kode tanpa mengubah perilakunya. Ini harus menjadi bagian rutin dari proses pengembangan, bukan proyek terpisah.

Disarankan mengalokasikan 20% waktu setiap sprint untuk refaktorisasi dan pembayaran utang teknis. Ini mencegah penumpukan "kekacauan" dan mempertahankan kecepatan tim dalam jangka panjang.

Code review wajib

Setiap pull request harus melewati review oleh setidaknya satu pengembang. Code review tidak hanya mendeteksi bug, tetapi juga pelanggaran arsitektur, gaya dan sumber potensial kode sampah.

Praktik baik — daftar periksa untuk code review yang mencakup pemeriksaan copy-paste, panjang metode, kompleksitas siklomatis dan cakupan tes. Tanpa daftar periksa, reviewer melewatkan hingga 50% masalah.

Alat untuk membersihkan basis kode

Alat analisis kode modern memungkinkan deteksi otomatis kode sampah, pengukuran utang teknis dan pengendalian kualitas. Integrasi alat-alat ini ke dalam pipeline CI/CD memberikan pemantauan berkelanjutan.

Disarankan menggunakan setidaknya satu penganalisis statis dan satu alat pengukuran metrik. Selain itu, platform untuk agregasi data kualitas kode dapat dihubungkan.

Penganalisis statis

• SonarQube — platform terkemuka untuk analisis kualitas kode, mendukung 30+ bahasa dan memberikan metrik Technical Debt Ratio
• ESLint — standar untuk JavaScript dan TypeScript, dikonfigurasi melalui file konfigurasi dan terintegrasi ke IDE
• SwiftLint — alat wajib untuk proyek iOS, memeriksa kepatuhan terhadap Swift Style Guide

Menurut data SonarSource, tim yang menggunakan analisis statis mengurangi jumlah bug di produksi sebesar 30% sudah pada kuartal pertama setelah penerapan.

Alat pengukuran metrik

CodeClimate dan Codacy — platform yang mengagregasi metrik kualitas kode, melacak dinamika dan menunjukkan "titik panas" — file dengan utang teknis terbesar.

Untuk proyek Android, Detekt menyediakan lebih dari 100 aturan analisis bawaan, termasuk pemeriksaan kompleksitas siklomatis, panjang metode dan duplikasi kode.