Salin-tempel dalam pengembangan aplikasi — apa itu, mengapa berbahaya dan bagaimana menghindarinya

Apa itu salin-tempel?

Salin-tempel (copy-paste programming) — adalah memindahkan kode yang sudah ada ke tempat baru dengan perubahan kecil atau tanpa perubahan. Istilah ini digunakan dalam arti merendahkan: ini menunjukkan bahwa pengembang tidak merancang solusi, tetapi secara mekanis menyalin blok yang sudah jadi, seringkali tanpa sepenuhnya memahami cara kerjanya.

Salin-tempel terdiri dari dua jenis: dibenarkan (intentional) dan tidak sengaja (accidental). Dibenarkan — ketika pengembang sengaja menyalin kode dengan rencana refactoring selanjutnya (tetapi rencana tersebut sering tidak dilaksanakan). Tidak sengaja — ketika duplikasi terjadi tanpa disadari, misalnya dua pengembang secara independen menulis logika yang sama untuk layar yang berbeda.

Menurut laporan SonarQube State of Clean Code (2025), kode duplikat rata-rata mencapai 12–18 persen dari total volume kode dalam proyek komersial. Sementara itu, biaya perbaikan bug dalam kode duplikat 2,5 kali lebih tinggi daripada kode dengan implementasi tunggal, karena pengembang harus menemukan dan memperbaiki semua salinan.

Alat utama untuk memerangi salin-tempel adalah prinsip DRY (Don't Repeat Yourself). Namun, memutlakkan DRY juga berbahaya: terkadang menyalin dibenarkan ketika dua salinan harus berevolusi secara independen satu sama lain. Penting untuk membedakan “duplikasi tidak sengaja” (yang harus dihilangkan) dan “duplikasi yang diperlukan” (yang harus didokumentasikan).

Mengapa salin-tempel berbahaya

Bahaya pertama dan paling utama — perkembangbiakan bug. Jika ada cacat dalam kode sumber, ia akan disalin ke semua tempat baru bersama dengan kode. Ketika cacat ditemukan dan diperbaiki di modul sumber, salinan tetap tidak diperbaiki. Pengembang mungkin tidak curiga bahwa bug ada di lima file berbeda.

Bahaya kedua — evolusi yang tidak merata. Dua salinan dari algoritma yang sama seiring waktu mendapatkan modifikasi yang berbeda. Di satu salinan ditambahkan validasi nilai batas, di salinan lain — format keluaran diubah. Setelah beberapa bulan, menjadi tidak mungkin untuk menentukan versi mana yang “benar” dan proyek kehilangan konsistensi perilaku.

Bahaya ketiga — peningkatan volume pengujian. Setiap salin-tempel memerlukan pengujiannya sendiri. Jika logika umum diekstrak ke dalam satu fungsi, ia dapat dicakup dengan satu set pengujian dan digunakan kembali. Dengan duplikasi, setiap salinan harus diuji secara terpisah — ini melipatgandakan waktu eksekusi CI dan volume basis pengujian yang dipelihara.

Bahaya keempat — ilusi produktivitas. Salin-tempel menciptakan perasaan kecepatan yang palsu: pengembang dengan cepat menyisipkan kode dan melihat bahwa layar berfungsi. Tetapi ‘kecepatan’ ini berubah menjadi utang teknis yang harus dibayar dengan bunga ketika bug ditemukan di blok duplikat atau ketika perubahan logika bisnis diperlukan.

Mengapa pengembang menyalin kode

Memahami penyebab salin-tempel membantu membangun pencegahan yang tepat. Paling sering, pengembang menyalin kode bukan karena malas, tetapi karena tekanan tenggat waktu, kurangnya pengetahuan, atau arsitektur yang tidak nyaman.

Alasan pertama — tenggat waktu. Ketika harus membuat layar dalam dua hari, dan layar serupa sudah ada, pengembang menyalinnya secara keseluruhan dan hanya mengubah apa yang dilihat pengguna. Untuk refactoring dengan mengekstrak komponen umum tidak ada waktu — klien mengharapkan hasil. Akibatnya, muncullah layar kedua dengan 80 persen kode umum, tetapi dengan riwayat perubahan yang independen.

Alasan kedua — kurangnya abstraksi tunggal. Jika dalam proyek tidak ada komponen umum untuk tugas tipikal (misalnya, layar daftar dengan pull-to-refresh), setiap pengembang akan menulis implementasinya sendiri atau menyalin milik tetangga. Keputusan arsitektur yang diambil di awal proyek secara langsung memengaruhi jumlah salin-tempel di masa depan.

Alasan ketiga — takut merusak kode yang berfungsi. Pengembang tahu bahwa modul yang ada berfungsi. Refactoring dengan mengekstrak kode umum dapat memengaruhi fungsionalitas yang ada. Jika cakupan pengujian rendah, risiko kerusakan melebihi manfaat refactoring yang dirasakan, dan pengembang memilih jalan aman — menyalin.

Hilangkan penyebabnya, bukan gejalanya. Memperpendek tenggat waktu dan menerapkan code review tidak akan menyelesaikan masalah jika dalam proyek tidak ada dasar arsitektur yang umum. Investasikan waktu dalam membuat komponen yang dapat digunakan kembali di tahap awal — ini adalah satu-satunya cara untuk mengurangi godaan salin-tempel di masa depan.

Alat deteksi duplikat

Pencarian salin-tempel dilakukan oleh penganalisis otomatis yang membandingkan fragmen kode dan menentukan kecocokan di atas ambang batas tertentu. Alat terbaik bekerja pada tingkat AST (pohon sintaksis abstrak) dan mengabaikan pemformatan, nama variabel, dan komentar.

PMD CPD (Copy-Paste Detector) — alat paling umum untuk Java, Kotlin, Swift, JavaScript, Python, dan C++. CPD menganalisis token kode sumber dan menemukan duplikat yang lebih panjang dari jumlah token minimum yang ditentukan (default 100). Menyetel ambang batas adalah kunci hasil yang berkualitas: ambang batas terlalu rendah memberikan banyak positif palsu (pola umum seperti import), ambang batas terlalu tinggi melewatkan duplikat nyata.

Menjalankan PMD CPD melalui Gradle

plugins {
    id 'pmd'
}

pmd {
    toolVersion = '7.0.0'
    ruleSetFiles = files("pmd-rules.xml")
}

tasks.register('cpd') {
    doLast {
        exec {
            workingDir = projectDir
            commandLine 'cpd',
                '--minimum-tokens', '75',
                '--language', 'kotlin',
                '--files', 'src/main/kotlin',
                '--format', 'xml',
                '--failOnViolation', 'true'
        }
    }
}

SonarQube menyematkan detektor duplikat langsung ke dalam Quality Gate. Aturan Duplicated Blocks (%) menunjukkan proporsi kode duplikat. Ambang batas 5 persen dianggap sehat untuk proyek komersial. Pelampauan memblokir promosi ke cabang rilis. SonarQube juga mengelompokkan duplikat berdasarkan jenis: salinan persis (exact match) dan salinan struktural (dengan nama yang diubah).

Untuk JavaScript dan TypeScript, duplikat dicari dengan ESLint dan plugin eslint-plugin-sonarjs (aturan no-duplicate-string) dan utilitas jscpd, yang mendukung 150+ bahasa. jscpd sangat nyaman untuk monorepo: ia menemukan duplikat antar paket, tidak hanya di dalam satu modul.

Strategi refactoring kode duplikat

Refactoring salin-tempel bermuara pada satu prinsip: ekstrak yang umum dan parametrisasi perbedaannya. Teknik spesifik tergantung pada volume duplikasi dan konteks.

Kasus paling sederhana — duplikasi dalam satu kelas (misalnya, dua metode dengan logika yang sama tetapi tipe berbeda). Solusi — generalisasi melalui generik atau menggunakan kembali metode dengan parameter tipe. Jika duplikasi mencakup beberapa kelas — ekstrak kode umum ke kelas utilitas atau fungsi ekstensi.

Kasus yang lebih kompleks — duplikasi di tingkat layar atau modul. Di sini ekstraksi fungsi sederhana tidak membantu, karena struktur UI, logika siklus hidup, dan pengikatan data terduplikasi. Solusi — buat kelas dasar layar yang umum atau komponen View komposit, dan kirimkan perbedaan melalui parameter atau protokol.

// sebelum - dua salinan UITableViewController yang sama
class UserListController: UITableViewController {
    private let viewModel = UserListViewModel()
    // 40 baris kode
}

class ProductListController: UITableViewController {
    private let viewModel = ProductListViewModel()
    // 40 baris yang sama tetapi dengan Product bukan User
}

// setelah - kelas dasar generik dibagikan
class ListViewController<T: ListViewModel>: UITableViewController {
    let viewModel: T
    // 40 baris kode - hanya sekali

    init(viewModel: T) {
        self.viewModel = viewModel
        super.init(style: .plain)
    }
}

Kasus paling kompleks — duplikasi antara layanan mikro atau pustaka. Mengekstrak kode umum dapat menyebabkan dependensi siklik atau penggabungan yang tidak perlu. Dalam kasus seperti itu, salin-tempel bisa menjadi keputusan sadar: dua tim memelihara layanan independen, dan pustaka bersama menimbulkan lebih banyak masalah daripada yang dipecahkan. Yang terpenting — dokumentasikan keputusan tersebut dan periksa secara teratur apakah salinan telah menyimpang begitu jauh sehingga waktunya untuk unifikasi.

Pencegahan salin-tempel di tingkat tim

Pencegahan salin-tempel lebih efektif daripada refactoring kode yang sudah terduplikasi. Tindakan pencegahan utama terletak pada organisasi proses pengembangan, bukan pada teknologi.

Tindakan pertama — code review dengan penekanan pada duplikasi. Daftar periksa review harus menyertakan poin: “Apakah PR ini berisi kode yang sudah ada di proyek?”. Jika peninjau melihat salin-tempel — dia memblokir penggabungan hingga komponen umum diekstrak. Persyaratan ini harus ditetapkan dalam Definition of Done tim.

Tindakan kedua — pustaka komponen bersama. Setiap pola UI yang muncul di dua layar atau lebih harus diekstrak ke modul bersama. Buat modul bersama di proyek dan jadikan itu titik masuk wajib untuk semua komponen UI. Jika komponen tidak ada — buat dulu, baru gunakan di layar.

Tindakan ketiga — otomatisasi di CI/CD. Tambahkan langkah ke pipeline dengan pemeriksaan kode duplikat (PMD CPD, jscpd, SonarQube). Pelampauan ambang batas — kesalahan build. Pengembang tidak dapat menggabungkan PR yang meningkatkan proporsi salin-tempel di atas tingkat yang diizinkan. Ini mengalihkan tanggung jawab dari code review ke otomatisasi dan menjamin tidak ada duplikat yang terlewatkan.

Terapkan budaya “satu implementasi — satu tempat”. Jika Anda melihat kemungkinan penggunaan kembali — jangan tunda refactoring. Setiap salin-tempel yang ditinggalkan “untuk nanti” akan berlipat ganda dan berubah menjadi utang teknis yang tidak terkendali.