Kopieer-plak in app-ontwikkeling — wat het is, waarom het gevaarlijk is en hoe je het kunt vermijden

Wat is kopieer-plak?

Kopieer-plak (copy-paste programming) — is het overbrengen van bestaande code naar een nieuwe plek met kleine wijzigingen of zonder wijzigingen. De term wordt in pejoratieve zin gebruikt: het suggereert dat de ontwikkelaar de oplossing niet ontwerpt, maar mechanisch een kant-en-klaar blok kopieert, vaak zonder volledig te begrijpen hoe het werkt.

Kopieer-plak komt in twee soorten voor: gerechtvaardigd (intentional) en toevallig (accidental). Gerechtvaardigd — wanneer de ontwikkelaar opzettelijk code kopieert met het plan voor latere refactoring (maar het plan wordt vaak niet uitgevoerd). Toevallig — wanneer duplicatie onopgemerkt ontstaat, bijvoorbeeld twee ontwikkelaars schrijven onafhankelijk dezelfde logica voor verschillende schermen.

Volgens het rapport SonarQube State of Clean Code (2025) vormt gedupliceerde code gemiddeld 12–18 procent van het totale codevolume in commerciële projecten. Tegelijkertijd zijn de kosten van het oplossen van een bug in gedupliceerde code 2,5 keer hoger dan in code met een uniforme implementatie, omdat de ontwikkelaar alle kopieën moet vinden en repareren.

Het belangrijkste hulpmiddel in de strijd tegen kopieer-plak is het principe DRY (Don't Repeat Yourself). Het absoluut stellen van DRY is echter ook gevaarlijk: soms is kopiëren gerechtvaardigd wanneer twee kopieën onafhankelijk van elkaar moeten evolueren. Het is belangrijk onderscheid te maken tussen “toevallige duplicatie” (die moet worden geëlimineerd) en “noodzakelijke duplicatie” (die moet worden gedocumenteerd).

Waarom kopieer-plak gevaarlijk is

Het eerste en belangrijkste gevaar — vermenigvuldiging van bugs. Als er in de broncode een defect zit, wordt dit samen met de code naar alle nieuwe plaatsen gekopieerd. Wanneer het defect wordt ontdekt en in de bronmodule wordt gerepareerd, blijven de kopieën ongerepareerd. De ontwikkelaar heeft misschien niet eens door dat de bug in vijf verschillende bestanden bestaat.

Het tweede gevaar — ongelijke evolutie. Twee kopieën van hetzelfde algoritme krijgen in de loop der tijd verschillende aanpassingen. In de ene kopie is validatie van randwaarden toegevoegd, in de andere — is het uitvoerformaat gewijzigd. Na een paar maanden wordt het onmogelijk te bepalen welke versie “correct” is en verliest het project consistentie in gedrag.

Het derde gevaar — toename van testvolume. Elke kopieer-plak vereist zijn eigen tests. Als de gemeenschappelijke logica in één functie wordt geëxtraheerd, kan deze met één testsuite worden gedekt en hergebruikt. Bij duplicatie moet elke kopie afzonderlijk worden getest — dit vermenigvuldigt de CI-doorlooptijd en de omvang van de te onderhouden testbasis.

Het vierde gevaar — illusie van productiviteit. Kopieer-plak creëert een vals gevoel van snelheid: de ontwikkelaar voegt snel code in en ziet dat het scherm werkt. Maar deze “snelheid” verandert in technische schuld die met rente moet worden terugbetaald wanneer er een bug wordt gevonden in het gedupliceerde blok of wanneer de bedrijfslogica moet worden gewijzigd.

Waarom ontwikkelaars code kopiëren

Inzicht in de oorzaken van kopieer-plak helpt bij het opzetten van de juiste preventie. Meestal kopiëren ontwikkelaars code niet uit luiheid, maar vanwege tijdsdruk, gebrek aan kennis of een onhandige architectuur.

De eerste reden — deadlines. Wanneer een scherm in twee dagen moet worden gemaakt en een vergelijkbaar scherm al bestaat, kopieert de ontwikkelaar het in zijn geheel en verandert alleen wat de gebruiker ziet. Voor refactoring met het extraheren van een gemeenschappelijke component is geen tijd — de klant verwacht een resultaat. Het gevolg is een tweede scherm met 80 procent gemeenschappelijke code, maar met een onafhankelijke wijzigingsgeschiedenis.

De tweede reden — gebrek aan uniforme abstractie. Als er in het project geen gemeenschappelijke component is voor een typische taak (bijvoorbeeld een lijstscherm met pull-to-refresh), zal elke ontwikkelaar zijn eigen implementatie schrijven of die van de buurman kopiëren. Architectuurbeslissingen die aan het begin van het project worden genomen, beïnvloeden direct de hoeveelheid toekomstige kopieer-plak.

De derde reden — angst om werkende code te breken. De ontwikkelaar weet dat de bestaande module werkt. Refactoring met het extraheren van gemeenschappelijke code kan de bestaande functionaliteit aantasten. Als de testdekking laag is, weegt het risico op breken zwaarder dan het waargenomen voordeel van refactoring, en kiest de ontwikkelaar voor de veilige weg — kopiëren.

Elimineer oorzaken, niet symptomen. Het verkorten van deadlines en het invoeren van code review zal het probleem niet oplossen als er in het project geen gemeenschappelijke architectuurbasis is. Investeer tijd in het creëren van herbruikbare componenten in een vroeg stadium — dit is de enige manier om de verleiding van kopieer-plak in de toekomst te verminderen.

Hulpmiddelen voor het detecteren van duplicaten

Het zoeken naar kopieer-plak wordt uitgevoerd door automatische analyzers die codefragmenten vergelijken en overeenkomsten boven een bepaalde drempel bepalen. De beste hulpmiddelen werken op AST-niveau (abstracte syntaxisboom) en negeren opmaak, variabelenamen en opmerkingen.

PMD CPD (Copy-Paste Detector) — het meest gebruikte hulpmiddel voor Java, Kotlin, Swift, JavaScript, Python en C++. CPD analyseert tokens van broncode en vindt duplicaten langer dan een ingesteld minimaal aantal tokens (standaard 100). Het instellen van de drempel is de sleutel tot een kwalitatief resultaat: een te lage drempel geeft veel vals-positieven (veelvoorkomende patronen zoals imports), een te hoge drempel mist echte duplicaten.

PMD CPD uitvoeren via 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 integreert de duplicatendetector rechtstreeks in de Quality Gate. De regel Duplicated Blocks (%) toont het aandeel gedupliceerde code. Een drempel van 5 procent wordt als gezond beschouwd voor commerciële projecten. Overschrijding blokkeert promotie naar de releasetak. SonarQube groepeert duplicaten bovendien op type: exacte kopieën (exact match) en structurele kopieën (met gewijzigde namen).

Voor JavaScript en TypeScript worden duplicaten gezocht met ESLint en de plugin eslint-plugin-sonarjs (regel no-duplicate-string) en met het hulpmiddel jscpd, dat 150+ talen ondersteunt. jscpd is bijzonder handig voor monorepo's: het vindt duplicaten tussen pakketten, niet alleen binnen één module.

Refactoringstrategieën voor gedupliceerde code

Refactoring van kopieer-plak komt neer op één principe: extraheer wat gemeenschappelijk is en parametriseer de verschillen. De specifieke techniek hangt af van de omvang van de duplicatie en de context.

Het eenvoudigste geval — duplicatie binnen één klasse (bijvoorbeeld twee methoden met dezelfde logica maar verschillende typen). Oplossing — generaliseren via generieken of de methode hergebruiken met een typeparameter. Als de duplicatie meerdere klassen omvat — extraheer de gemeenschappelijke code naar een utility-klasse of extensiefunctie.

Een complexer geval — duplicatie op scherm- of moduleniveau. Hier helpt het simpelweg extraheren van een functie niet, omdat de UI-structuur, levenscycluslogica en databinding worden gedupliceerd. Oplossing — maak een gemeenschappelijke basisklasse voor het scherm of een samengestelde View-component en geef de verschillen door via parameters of protocol.

// voor - twee kopieën van dezelfde UITableViewController
class UserListController: UITableViewController {
    private let viewModel = UserListViewModel()
    // 40 regels code
}

class ProductListController: UITableViewController {
    private let viewModel = ProductListViewModel()
    // dezelfde 40 regels maar met Product in plaats van User
}

// na - gedeelde basisklasse
class ListViewController<T: ListViewModel>: UITableViewController {
    let viewModel: T
    // 40 regels code - slechts één keer

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

Het meest complexe geval — duplicatie tussen microservices of bibliotheken. Het extraheren van gemeenschappelijke code kan leiden tot cyclische afhankelijkheden of ongewenste koppeling. In dergelijke gevallen kan kopieer-plak een bewuste beslissing zijn: twee teams onderhouden onafhankelijke diensten en een gedeelde bibliotheek veroorzaakt meer problemen dan het oplost. Het belangrijkste is om een dergelijke beslissing te documenteren en regelmatig te controleren of de kopieën niet zo ver uit elkaar zijn gegroeid dat het tijd is voor unificatie.

Preventie van kopieer-plak op teamniveau

Preventie van kopieer-plak is effectiever dan refactoring van reeds gedupliceerde code. De belangrijkste preventieve maatregelen liggen in de organisatie van het ontwikkelproces, niet in technologieën.

De eerste maatregel — code review met nadruk op duplicatie. De checklist van de review moet het punt bevatten: “Bevat deze PR code die al in het project bestaat?”. Als de reviewer kopieer-plak ziet, blokkeert hij de merge totdat de gemeenschappelijke component is geëxtraheerd. Deze vereiste moet worden vastgelegd in de Definition of Done van het team.

De tweede maatregel — gedeelde componentenbibliotheek. Elk UI-patroon dat op twee of meer schermen voorkomt, moet worden geëxtraheerd naar een gemeenschappelijke module. Maak een gedeelde module in het project en maak het een verplicht toegangspunt voor alle UI-componenten. Als een component niet bestaat — maak hem eerst aan, gebruik hem dan pas op het scherm.

De derde maatregel — automatisering in CI/CD. Voeg een stap toe aan de pipeline met het controleren van gedupliceerde code (PMD CPD, jscpd, SonarQube). Overschrijding van de drempel — buildfout. De ontwikkelaar kan geen PR mergen die het aandeel kopieer-plak boven het toegestane niveau verhoogt. Dit verlegt de verantwoordelijkheid van code review naar automatisering en garandeert dat geen enkel duplicaat wordt gemist.

Voer de cultuur in van “één implementatie — één plek”. Als u een mogelijkheid tot hergebruik ziet, stel refactoring dan niet uit. Elke kopieer-plak die “voor later” wordt bewaard, vermenigvuldigt zich en verandert in onbeheersbare technische schuld.