Kopiera-klistra i apputveckling — vad det är, varför det är farligt och hur man undviker det

Vad är kopiera-klistra?

Kopiera-klistra (copy-paste programming) — är att överföra befintlig kod till en ny plats med små ändringar eller utan ändringar. Termen används i nedsättande bemärkelse: den antyder att utvecklaren inte designar lösningen utan mekaniskt kopierar ett färdigt block, ofta utan att fullt ut förstå hur det fungerar.

Kopiera-klistra finns i två typer: berättigad (intentional) och oavsiktlig (accidental). Berättigad — när utvecklaren avsiktligt kopierar kod med plan för senare refaktorering (men planen utförs ofta inte). Oavsiktlig — när duplicering uppstår obemärkt, till exempel två utvecklare skriver oberoende av varandra samma logik för olika skärmar.

Enligt rapporten SonarQube State of Clean Code (2025) utgör duplicerad kod i genomsnitt 12–18 procent av den totala kodvolymen i kommersiella projekt. Samtidigt är kostnaden för att fixa en bugg i duplicerad kod 2,5 gånger högre än i kod med enhetlig implementering, eftersom utvecklaren måste hitta och fixa alla kopior.

Det främsta verktyget i kampen mot kopiera-klistra är principen DRY (Don't Repeat Yourself). Att göra DRY till ett absolut krav är dock också farligt: ibland är kopiering berättigad när två kopior måste utvecklas oberoende av varandra. Det är viktigt att skilja mellan “oavsiktlig duplicering” (som måste elimineras) och “nödvändig duplicering” (som måste dokumenteras).

Varför är kopiera-klistra farligt

Den första och viktigaste faran — förökning av buggar. Om det finns en defekt i källkoden kopieras den till alla nya platser tillsammans med koden. När defekten upptäcks och fixas i källmodulen förblir kopiorna ofixade. Utvecklaren kanske inte ens misstänker att buggen finns i fem olika filer.

Den andra faran — ojämn utveckling. Två kopior av samma algoritm får med tiden olika modifieringar. I en kopia lades validering av gränsvärden till, i den andra — ändrades utdataformatet. Efter några månader blir det omöjligt att avgöra vilken version som är “korrekt” och projektet förlorar beteendekonsistens.

Den tredje faran — ökad testvolym. Varje kopiera-klistra kräver egna tester. Om den gemensamma logiken extraheras till en funktion kan den täckas av en testsvit och återanvändas. Vid duplicering måste varje kopia testas separat — detta mångfaldigar CI-körtiden och volymen på den underhållna testbasen.

Den fjärde faran — illusion av produktivitet. Kopiera-klistra skapar en falsk känsla av hastighet: utvecklaren infogar snabbt kod och ser att skärmen fungerar. Men detta “snabba” sätt förvandlas till teknisk skuld som måste betalas tillbaka med ränta när en bugg hittas i det duplicerade blocket eller en ändring av affärslogiken krävs.

Varför utvecklare kopierar kod

Att förstå orsakerna till kopiera-klistra hjälper till att bygga rätt förebyggande. Oftast kopierar utvecklare kod inte av lättja, utan på grund av tidspress, kunskapsbrist eller obekväm arkitektur.

Den första orsaken — deadlines. När en skärm måste göras på två dagar och en liknande skärm redan finns, kopierar utvecklaren den i sin helhet och ändrar bara vad användaren ser. För refaktorering med extrahering av en gemensam komponent finns ingen tid — kunden förväntar sig ett resultat. Resultatet blir en andra skärm med 80 procent gemensam kod, men med oberoende ändringshistorik.

Den andra orsaken — brist på enhetlig abstraktion. Om det i projektet inte finns någon gemensam komponent för en typisk uppgift (till exempel en listskärm med pull-to-refresh), kommer varje utvecklare att skriva sin egen implementering eller kopiera grannens. Arkitektoniska beslut som fattas i början av projektet påverkar direkt mängden framtida kopiera-klistra.

Den tredje orsaken — rädsla för att bryta fungerande kod. Utvecklaren vet att den befintliga modulen fungerar. Refaktorering med extrahering av gemensam kod kan påverka befintlig funktionalitet. Om testtäckningen är låg överväger risken för brott den upplevda fördelen med refaktorering, och utvecklaren väljer den säkra vägen — kopiering.

Eliminera orsakerna, inte symptomen. Att förkorta deadlines och införa code review kommer inte att lösa problemet om projektet saknar en gemensam arkitektonisk bas. Investera tid i att skapa återanvändbara komponenter i tidiga skeden — det är det enda sättet att minska frestelsen till kopiera-klistra i framtiden.

Verktyg för att upptäcka duplikat

Sökning efter kopiera-klistra utförs av automatiska analyseatorer som jämför kodfragment och bestämmer träffar över ett inställt tröskelvärde. De bästa verktygen arbetar på AST-nivå (abstrakt syntaxträd) och ignorerar formatering, variabelnamn och kommentarer.

PMD CPD (Copy-Paste Detector) — det mest använda verktyget för Java, Kotlin, Swift, JavaScript, Python och C++. CPD analyserar källkodens token och hittar duplikat längre än ett inställt minsta antal token (standard 100). Att ställa in tröskelvärdet är nyckeln till ett kvalitativt resultat: ett för lågt tröskelvärde ger många falska positiva (vanliga mönster som imports), ett för högt missar verkliga duplikat.

Köra PMD CPD 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 bäddar in duplikatdetektorn direkt i Quality Gate. Regeln Duplicated Blocks (%) visar andelen duplicerad kod. Ett tröskelvärde på 5 procent anses hälsosamt för kommersiella projekt. Överskridning blockerar befordran till releasegrenen. SonarQube grupperar dessutom duplikat efter typ: exakta kopior (exact match) och strukturella kopior (med ändrade namn).

För JavaScript och TypeScript söks duplikat med ESLint och plugin-programmet eslint-plugin-sonarjs (regeln no-duplicate-string) och verktyget jscpd, som stöder 150+ språk. jscpd är särskilt bekvämt för monorepon: det hittar duplikat mellan paket, inte bara inom en modul.

Refaktoringsstrategier för duplicerad kod

Refaktorering av kopiera-klistra handlar om en princip: extrahera det gemensamma och parametrisera skillnaderna. Den specifika tekniken beror på dupliceringens omfattning och sammanhang.

Det enklaste fallet — duplicering inom en klass (till exempel två metoder med samma logik men olika typer). Lösning — generalisera via generics eller återanvända metoden med en typparameter. Om dupliceringen omfattar flera klasser — extrahera den gemensamma koden till en verktygsklass eller extensionsfunktion.

Ett mer komplext fall — duplicering på skärm- eller modulnivå. Här hjälper inte enkel funktionsextrahering, eftersom UI-strukturen, livscykellogiken och databindningen dupliceras. Lösning — skapa en gemensam basklass för skärmen eller en sammansatt View-komponent och skicka skillnaderna via parametrar eller protokoll.

// före - två kopior av samma UITableViewController
class UserListController: UITableViewController {
    private let viewModel = UserListViewModel()
    // 40 rader kod
}

class ProductListController: UITableViewController {
    private let viewModel = ProductListViewModel()
    // samma 40 rader men med Product istället för User
}

// efter - delad generisk basklass
class ListViewController<T: ListViewModel>: UITableViewController {
    let viewModel: T
    // 40 rader kod - endast en gång

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

Det mest komplexa fallet — duplicering mellan mikrotjänster eller bibliotek. Att extrahera gemensam kod kan leda till cykliska beroenden eller oönskad koppling. I sådana fall kan kopiera-klistra vara ett medvetet beslut: två team underhåller oberoende tjänster och ett gemensamt bibliotek skapar fler problem än det löser. Det viktigaste — dokumentera ett sådant beslut och kontrollera regelbundet om kopiorna har divergerat så mycket att det är dags för enhetliggörande.

Förebygga kopiera-klistra på teamnivå

Förebyggande av kopiera-klistra är effektivare än refaktorering av redan duplicerad kod. De viktigaste förebyggande åtgärderna ligger i organisationen av utvecklingsprocessen, inte i tekniken.

Den första åtgärden — code review med betoning på duplicering. Granskningslistan bör innehålla punkten: “Finns det kod i denna PR som redan finns i projektet?”. Om granskaren ser kopiera-klistra — blockerar han sammanslagningen tills den gemensamma komponenten har extraherats. Detta krav bör fastställas i teamets Definition of Done.

Den andra åtgärden — delad komponentbibliotek. Varje UI-mönster som förekommer på två eller fler skärmar bör extraheras till en gemensam modul. Skapa en delad modul i projektet och gör den till obligatorisk ingångspunkt för alla UI-komponenter. Om komponenten inte finns — skapa den först, använd den sedan på skärmen.

Den tredje åtgärden — automatisering i CI/CD. Lägg till ett steg i pipeline med kontroll av duplicerad kod (PMD CPD, jscpd, SonarQube). Överskridning av tröskelvärdet — byggfel. Utvecklaren kan inte slå samman en PR som ökar andelen kopiera-klistra över tillåten nivå. Detta flyttar ansvaret från code review till automatisering och garanterar att inget duplikat missas.

Inför kulturen ”en implementering — en plats”. Om du ser en möjlighet till återanvändning — skjut inte upp refaktoreringen. Varje kopiera-klistra som lämnas “till senare” multipliceras och förvandlas till okontrollerbar teknisk skuld.