Kopírování-vkládání při vývoji aplikací — co to je, proč je nebezpečné a jak se mu vyhnout

Co je kopírování-vkládání?

Kopírování-vkládání (copy-paste programming) — je přenos existujícího kódu na nové místo s malými změnami nebo bez nich. Termín se používá v pejorativním smyslu: naznačuje, že vývojář nenavrhuje řešení, ale mechanicky kopíruje hotový blok, často bez úplného pochopení toho, jak funguje.

Kopírování-vkládání je dvou typů: oprávněné (intentional) a náhodné (accidental). Oprávněné — když vývojář úmyslně kopíruje kód s plánem pozdějšího refaktorování (ale plán se často neuskuteční). Náhodné — když duplikace vznikne nepozorovaně, například dva vývojáři nezávisle napíší stejnou logiku pro různé obrazovky.

Podle zprávy SonarQube State of Clean Code (2025) tvoří duplikovaný kód v průměru 12–18 procent celkového objemu kódu v komerčních projektech. Současně jsou náklady na opravu chyby v duplikovaném kódu 2,5krát vyšší než v kódu s jednotnou implementací, protože vývojář musí najít a opravit všechny kopie.

Hlavním nástrojem boje proti kopírování-vkládání je princip DRY (Don't Repeat Yourself). Avšak absolutizace DRY je také nebezpečná: někdy je kopírování oprávněné, když dvě kopie musí evolvovat nezávisle na sobě. Je důležité rozlišovat „náhodnou duplikaci“ (kterou je třeba odstranit) a „nutnou duplikaci“ (kterou je třeba dokumentovat).

Proč je kopírování-vkládání nebezpečné

První a nejdůležitější nebezpečí — množení chyb. Pokud je ve zdrojovém kódu vada, je spolu s kódem zkopírována na všechna nová místa. Když je vada objevena a opravena ve zdrojovém modulu, kopie zůstávají neopravené. Vývojář může dokonce netušit, že chyba existuje v pěti různých souborech.

Druhé nebezpečí — nerovnoměrná evoluce. Dvě kopie stejného algoritmu časem získávají různé úpravy. V jedné kopii byla přidána validace okrajových hodnot, ve druhé — změněn formát výstupu. Po několika měsících je nemožné určit, která verze je „správná“, a projekt ztrácí konzistenci chování.

Třetí nebezpečí — zvýšení objemu testů. Každé kopírování-vkládání vyžaduje vlastní testy. Pokud je společná logika extrahována do jedné funkce, lze ji pokrýt jednou sadou testů a znovu použít. Při duplikaci je třeba každou kopii testovat samostatně — to mnohonásobně zvyšuje dobu běhu CI a objem udržované testovací základny.

Čtvrté nebezpečí — iluze produktivity. Kopírování-vkládání vytváří falešný pocit rychlosti: vývojář rychle vloží kód a vidí, že obrazovka funguje. Ale tato „rychlost“ se mění v technický dluh, který bude třeba splatit i s úroky, když se v duplikovaném bloku najde chyba nebo bude vyžadována změna obchodní logiky.

Proč vývojáři kopírují kód

Pochopení příčin kopírování-vkládání pomáhá vybudovat správnou prevenci. Nejčastěji vývojáři kopírují kód nikoli z lenosti, ale kvůli tlaku termínů, nedostatku znalostí nebo nepohodlné architektuře.

První důvod — termíny. Když je třeba vytvořit obrazovku za dva dny a podobná obrazovka již existuje, vývojář ji zkopíruje celou a změní pouze to, co uživatel vidí. Na refaktorování s extrakcí společné komponenty není čas — klient očekává výsledek. V důsledku toho vzniká druhá obrazovka s 80 procenty společného kódu, ale s nezávislou historií změn.

Druhý důvod — nedostatek jednotné abstrakce. Pokud v projektu neexistuje společná komponenta pro typický úkol (například obrazovka seznamu s pull-to-refresh), každý vývojář napíše svou vlastní implementaci nebo zkopíruje sousední. Architektonická rozhodnutí učiněná na začátku projektu přímo ovlivňují množství budoucího kopírování-vkládání.

Třetí důvod — strach z rozbití fungujícího kódu. Vývojář ví, že existující modul funguje. Refaktorování s extrakcí společného kódu může ovlivnit stávající funkčnost. Pokud je pokrytí testy nízké, riziko rozbití převyšuje vnímaný přínos refaktorování a vývojář volí bezpečnou cestu — kopírování.

Odstraňujte příčiny, ne příznaky. Zkrácení termínů a zavedení code review nevyřeší problém, pokud v projektu chybí společná architektonická základna. Investujte čas do vytváření znovupoužitelných komponent v raných fázích — to je jediný způsob, jak snížit pokušení kopírování-vkládání v budoucnosti.

Nástroje pro detekci duplikátů

Vyhledávání kopírování-vkládání provádějí automatické analyzátory, které porovnávají fragmenty kódu a určují shody nad nastavenou prahovou hodnotou. Nejlepší nástroje pracují na úrovni AST (abstraktního syntaktického stromu) a ignorují formátování, názvy proměnných a komentáře.

PMD CPD (Copy-Paste Detector) — nejrozšířenější nástroj pro Java, Kotlin, Swift, JavaScript, Python a C++. CPD analyzuje tokeny zdrojového kódu a nachází duplikáty delší než nastavený minimální počet tokenů (výchozí 100). Nastavení prahu je klíčem ke kvalitnímu výsledku: příliš nízký práh dává mnoho falešných pozitiv (běžné vzory jako importy), příliš vysoký — propouští skutečné duplikáty.

Spuštění PMD CPD přes 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 vestaví detektor duplikátů přímo do Quality Gate. Pravidlo Duplicated Blocks (%) ukazuje podíl duplikovaného kódu. Práh 5 procent je považován za zdravý pro komerční projekty. Překročení blokuje propagaci do release větve. SonarQube navíc seskupuje duplikáty podle typu: přesné kopie (exact match) a strukturální kopie (se změněnými názvy).

Pro JavaScript a TypeScript se duplikáty hledají pomocí ESLintu s pluginem eslint-plugin-sonarjs (pravidlo no-duplicate-string) a nástrojem jscpd, který podporuje 150+ jazyků. jscpd je zvlášť vhodný pro monorepozitáře: nachází duplikáty mezi balíčky, nejen uvnitř jednoho modulu.

Strategie refaktorování duplikovaného kódu

Refaktorování kopírování-vkládání se scvrkává na jeden princip: extrahovat společné a parametrizovat rozdíly. Konkrétní technika závisí na rozsahu duplikace a kontextu.

Nejjednodušší případ — duplikace v jedné třídě (například dvě metody se stejnou logikou, ale odlišnými typy). Řešení — zobecnit pomocí generik nebo znovu použít metodu s parametrem typu. Pokud duplikace pokrývá několik tříd — extrahovat společný kód do utilitní třídy nebo extension funkce.

Složitější případ — duplikace na úrovni obrazovek nebo modulů. Zde jednoduchá extrakce funkce nepomáhá, protože se duplikuje struktura UI, logika životního cyklu a vázání dat. Řešení — vytvořit společnou základní třídu obrazovky nebo kompozitní View komponentu a rozdíly předávat prostřednictvím parametrů nebo protokolu.

// před - dvě kopie stejného UITableViewController
class UserListController: UITableViewController {
    private let viewModel = UserListViewModel()
    // 40 řádků kódu
}

class ProductListController: UITableViewController {
    private let viewModel = ProductListViewModel()
    // stejných 40 řádků, ale s Product místo User
}

// po - sdílená generická základní třída
class ListViewController<T: ListViewModel>: UITableViewController {
    let viewModel: T
    // 40 řádků kódu - pouze jednou

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

Nejsložitější případ — duplikace mezi mikroslužbami nebo knihovnami. Extrakce společného kódu může vést k cyklickým závislostem nebo neopodstatněnému provázání. V takových případech může být kopírování-vkládání vědomým rozhodnutím: dva týmy udržují nezávislé služby a společná knihovna vytváří více problémů, než řeší. Nejdůležitější — takové rozhodnutí dokumentovat a pravidelně kontrolovat, zda se kopie nerozešly natolik, že je čas na sjednocení.

Prevence kopírování-vkládání na úrovni týmu

Prevence kopírování-vkládání je účinnější než refaktorování již duplikovaného kódu. Hlavní preventivní opatření spočívají v organizaci vývojového procesu, nikoli v technologiích.

První opatření — code review s důrazem na duplikaci. Kontrolní seznam recenze by měl obsahovat bod: „Není v tomto PR kód, který již v projektu existuje?“. Pokud recenzent vidí kopírování-vkládání — blokuje sloučení do extrakce společné komponenty. Tento požadavek by měl být zakotven v Definition of Done týmu.

Druhé opatření — sdílená knihovna komponent. Každý UI vzor, který se vyskytuje na dvou nebo více obrazovkách, by měl být extrahován do společného modulu. Vytvořte sdílený modul v projektu a učiňte ho povinným vstupním bodem pro všechny UI komponenty. Pokud komponenta neexistuje — nejprve ji vytvořte, pak teprve použijte na obrazovce.

Třetí opatření — automatizace v CI/CD. Přidejte do pipeline krok s kontrolou duplikovaného kódu (PMD CPD, jscpd, SonarQube). Překročení prahu — chyba sestavení. Vývojář nemůže sloučit PR, který zvyšuje podíl kopírování-vkládání nad povolenou úroveň. To přesouvá odpovědnost z code review na automatizaci a zaručuje, že žádný duplikát nebude přehlédnut.

Zavádějte kulturu „jedna implementace — jedno místo“. Pokud vidíte možnost znovupoužití — neodkládejte refaktorování na později. Každé kopírování-vkládání ponechané „na později“ se množí a mění v nezvladatelný technický dluh.