Másolás-beillesztés az alkalmazásfejlesztésben — mi ez, miért veszélyes és hogyan kerülhető el

Mi a másolás-beillesztés?

Másolás-beillesztés (copy-paste programming) — a meglévő kód áthelyezése egy új helyre kisebb módosításokkal vagy azok nélkül. A kifejezést pejoratív értelemben használják: azt sugallja, hogy a fejlesztő nem tervezi a megoldást, hanem mechanikusan másol egy kész blokkot, gyakran anélkül, hogy teljesen megértené, hogyan működik.

A másolás-beillesztés kétféle lehet: indokolt (intentional) és véletlen (accidental). Indokolt — amikor a fejlesztő szándékosan másol kódot egy későbbi refaktorálás tervével (de a terv gyakran nem valósul meg). Véletlen — amikor a duplikáció észrevétlenül keletkezik, például két fejlesztő egymástól függetlenül ugyanazt a logikát írja meg különböző képernyőkhöz.

A SonarQube State of Clean Code (2025) jelentése szerint a duplikált kód átlagosan a teljes kódmennyiség 12–18 százalékát teszi ki a kereskedelmi projektekben. Ugyanakkor a hiba javításának költsége a duplikált kódban 2,5-szer magasabb, mint az egységes implementációjú kódban, mert a fejlesztőnek meg kell találnia és ki kell javítania az összes másolatot.

A másolás-beillesztés elleni küzdelem fő eszköze a DRY (Don't Repeat Yourself) elv. Azonban a DRY abszolutizálása is veszélyes: néha a másolás indokolt, amikor két másolatnak egymástól függetlenül kell fejlődnie. Fontos megkülönböztetni a „véletlen duplikációt” (amit meg kell szüntetni) és a „szükséges duplikációt” (amit dokumentálni kell).

Miért veszélyes a másolás-beillesztés

Az első és legfontosabb veszély — a hibák elszaporodása. Ha a forráskódban hiba van, az a kóddal együtt minden új helyre átmásolódik. Amikor a hibát felfedezik és kijavítják a forrásmodulban, a másolatok javítatlanul maradnak. A fejlesztő talán még csak nem is sejti, hogy a hiba öt különböző fájlban létezik.

A második veszély — egyenlőtlen evolúció. Ugyanazon algoritmus két másolata idővel eltérő módosításokat halmoz fel. Az egyik másolatban hozzáadták a határértékek érvényesítését, a másikban — megváltoztatták a kimeneti formátumot. Néhány hónap múlva lehetetlenné válik meghatározni, melyik verzió a „helyes”, és a projekt elveszíti a viselkedés konzisztenciáját.

A harmadik veszély — a tesztek mennyiségének növekedése. Minden másolás-beillesztés saját teszteket igényel. Ha a közös logikát egyetlen függvénybe emeljük ki, azt egy teszthalmazzal lefedhetjük és újra felhasználhatjuk. Duplikáció esetén minden másolatot külön kell tesztelni — ez többszörösére növeli a CI futási idejét és a karbantartott tesztbázis méretét.

A negyedik veszély — a termelékenység illúziója. A másolás-beillesztés hamis sebességérzetet kelt: a fejlesztő gyorsan beilleszti a kódot, és látja, hogy a képernyő működik. De ez a „sebesség” technikai adóssággá válik, amelyet kamatostul kell visszafizetni, amikor a duplikált blokkban hibát találnak, vagy az üzleti logika megváltoztatására van szükség.

Miért másolnak kódot a fejlesztők

A másolás-beillesztés okainak megértése segít a helyes megelőzés kialakításában. A fejlesztők leggyakrabban nem lustaságból másolnak kódot, hanem határidők nyomása, tudáshiány vagy kényelmetlen architektúra miatt.

Az első ok — határidők. Amikor egy képernyőt két nap alatt kell elkészíteni, és egy hasonló képernyő már létezik, a fejlesztő azt teljes egészében lemásolja, és csak azt változtatja meg, amit a felhasználó lát. A közös komponens kiemelésével járó refaktorálásra nincs idő — az ügyfél eredményt vár. Ennek eredményeként létrejön egy második képernyő 80 százalék közös kóddal, de független módosítási előzményekkel.

A második ok — az egységes absztrakció hiánya. Ha a projektben nincs közös komponens egy tipikus feladatra (például egy listaképernyő pull-to-refresh funkcióval), minden fejlesztő megírja a saját implementációját, vagy lemásolja a szomszédosét. A projekt kezdetén hozott architekturális döntések közvetlenül befolyásolják a jövőbeli másolás-beillesztés mennyiségét.

A harmadik ok — félelem a működő kód elrontásától. A fejlesztő tudja, hogy a meglévő modul működik. A közös kód kiemelésével járó refaktorálás befolyásolhatja a meglévő funkcionalitást. Ha a tesztlefedettség alacsony, a törés kockázata meghaladja a refaktorálás észlelt előnyét, és a fejlesztő a biztonságos utat választja — a másolást.

Szüntesse meg az okokat, ne a tüneteket. A határidők lerövidítése és a code review bevezetése nem oldja meg a problémát, ha a projektből hiányzik a közös architekturális alap. Fektessen be időt a újrahasználható komponensek létrehozásába a korai szakaszokban — ez az egyetlen módja a másolás-beillesztés csábításának csökkentésére a jövőben.

Duplikátumok észlelésének eszközei

A másolás-beillesztés keresését automatikus elemzők végzik, amelyek összehasonlítják a kódrészleteket, és meghatározzák az egyezéseket egy adott küszöbérték felett. A legjobb eszközök AST (absztrakt szintaxisfa) szinten működnek, és figyelmen kívül hagyják a formázást, a változóneveket és a megjegyzéseket.

PMD CPD (Copy-Paste Detector) — a legelterjedtebb eszköz Java, Kotlin, Swift, JavaScript, Python és C++ nyelvekhez. A CPD elemzi a forráskód tokenjeit, és megtalálja a megadott minimális tokenszámnál (alapértelmezés szerint 100) hosszabb duplikátumokat. A küszöbérték beállítása kulcsfontosságú a minőségi eredményhez: a túl alacsony küszöb sok hamis pozitív találatot ad (gyakori minták, mint az importok), a túl magas pedig kihagyja a valódi duplikátumokat.

PMD CPD futtatása Gradle-lel

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 beépíti a duplikátumdetektort közvetlenül a Quality Gate-be. A Duplicated Blocks (%) szabály a duplikált kód arányát mutatja. Az 5 százalékos küszöb egészségesnek tekinthető kereskedelmi projektek esetében. A túllépés blokkolja a promóciót a kiadási ágba. A SonarQube emellett típus szerint csoportosítja a duplikátumokat: pontos másolatok (exact match) és strukturális másolatok (módosított nevekkel).

JavaScript és TypeScript esetében a duplikátumokat az ESLint eslint-plugin-sonarjs bővítménnyel (no-duplicate-string szabály) és a jscpd segédprogrammal keresik, amely 150+ nyelvet támogat. A jscpd különösen kényelmes monorepókhoz: a csomagok között talál duplikátumokat, nem csak egy modulon belül.

A duplikált kód refaktorálási stratégiái

A másolás-beillesztés refaktorálása egyetlen elvre vezethető vissza: emelje ki a közöst és paraméterezze a különbségeket. A konkrét technika a duplikáció mértékétől és a kontextustól függ.

A legegyszerűbb eset — duplikáció egy osztályon belül (például két metódus azonos logikával, de eltérő típusokkal). Megoldás — általánosítás generikusokkal vagy a metódus újrafelhasználása típusparaméterrel. Ha a duplikáció több osztályra terjed ki — emelje ki a közös kódot egy segédosztályba vagy kiterjesztő függvénybe.

Bonyolultabb eset — duplikáció képernyők vagy modulok szintjén. Itt az egyszerű függvénykiemelés nem segít, mert az UI-struktúra, az életciklus-logika és az adatkötés duplikálódik. Megoldás — hozzon létre egy közös alaposztályt a képernyőhöz vagy egy összetett View-komponenst, és a különbségeket paramétereken vagy protokollon keresztül adja át.

// előtt - ugyanannak a UITableViewController-nek két másolata
class UserListController: UITableViewController {
    private let viewModel = UserListViewModel()
    // 40 sor kód
}

class ProductListController: UITableViewController {
    private let viewModel = ProductListViewModel()
    // ugyanaz a 40 sor, de Product-tal User helyett
}

// után - megosztott általános alaposztály
class ListViewController<T: ListViewModel>: UITableViewController {
    let viewModel: T
    // 40 sor kód - csak egyszer

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

A legbonyolultabb eset — duplikáció mikroszolgáltatások vagy könyvtárak között. A közös kód kiemelése ciklikus függőségekhez vagy indokolatlan összekapcsolódáshoz vezethet. Ilyen esetekben a másolás-beillesztés tudatos döntés lehet: két csapat független szolgáltatásokat tart fenn, és egy közös könyvtár több problémát okoz, mint amennyit megold. A legfontosabb — dokumentálni az ilyen döntést, és rendszeresen ellenőrizni, hogy a másolatok nem tértek-e el annyira, hogy itt az ideje az egységesítésnek.

A másolás-beillesztés megelőzése csapatszinten

A másolás-beillesztés megelőzése hatékonyabb, mint a már duplikált kód refaktorálása. A fő megelőző intézkedések a fejlesztési folyamat megszervezésében rejlenek, nem a technológiákban.

Az első intézkedés — code review a duplikációra összpontosítva. A felülvizsgálati ellenőrzőlistának tartalmaznia kell a következő pontot: „Van-e ebben a PR-ben olyan kód, amely már létezik a projektben?”. Ha a bíráló másolás-beillesztést lát — blokkolja az egyesítést a közös komponens kiemeléséig. Ezt a követelményt rögzíteni kell a csapat Definition of Done-jában.

A második intézkedés — közös komponenskönyvtár. Minden olyan UI-mintát, amely két vagy több képernyőn előfordul, ki kell emelni egy közös modulba. Hozzon létre egy megosztott modult a projektben, és tegye azt kötelező belépési ponttá az összes UI-komponens számára. Ha a komponens nem létezik — először hozza létre, majd használja a képernyőn.

A harmadik intézkedés — automatizálás a CI/CD-ben. Adjon hozzá egy lépést a csővezetékhez a duplikált kód ellenőrzésével (PMD CPD, jscpd, SonarQube). A küszöb túllépése — build-hiba. A fejlesztő nem egyesíthet egy olyan PR-t, amely a másolás-beillesztés arányát a megengedett szint fölé emeli. Ez áthelyezi a felelősséget a code review-ról az automatizálásra, és garantálja, hogy egyetlen duplikátum sem marad ki.

Vezesse be az ‚tegy implementáció — egy hely” kultúrát. Ha látja az újrafelhasználás lehetőségét — ne halassza későbbre a refaktorálást. Minden „későbbre” hagyott másolás-beillesztés megsokszorozódik és ellenőrizhetetlen technikai adóssággá válik.