Копіпаста в розробці додатків — що це, чим небезпечна та як уникати

Що таке копіпаста?

Копіпаста (copy-paste programming) — це перенесення наявного коду в нове місце з незначними змінами або без них. Термін використовується в зневажливому сенсі: він передбачає, що розробник не проєктує рішення, а механічно копіює готовий блок, часто не до кінця розуміючи, як він працює.

Копіпаста буває двох видів: виправдана (intentional) і випадкова (accidental). Виправдана — коли розробник навмисно копіює код із планом подальшого рефакторингу (але часто план не виконується). Випадкова — коли дублювання виникає непомітно, наприклад, два розробники незалежно пишуть одну й ту саму логіку для різних екранів.

За даними звіту SonarQube State of Clean Code (2025), дубльований код становить у середньому 12–18 відсотків загального обсягу коду в комерційних проєктах. При цьому вартість виправлення бага в дубльованому коді в 2.5 раза вища, ніж у коді з єдиною реалізацією, тому що розробник повинен знайти й виправити всі копії.

Основний інструмент боротьби з копіпастою — принцип DRY (Don't Repeat Yourself). Однак абсолютизувати DRY теж небезпечно: іноді копіювання виправдане, коли дві копії мають еволюціонувати незалежно одна від одної. Важливо розрізняти «випадкове дублювання» (яке треба усувати) і «необхідне дублювання» (яке треба документувати).

Чим небезпечна копіпаста

Перша й головна небезпека — розмноження багів. Якщо у вихідному коді є дефект, він копіюється в усі нові місця разом із кодом. Коли дефект виявляють і виправляють у вихідному модулі, копії залишаються невиправленими. Розробник може навіть не підозрювати, що баг існує в п'яти різних файлах.

Друга небезпека — нерівномірна еволюція. Дві копії одного алгоритму з часом обростають різними правками. В одній копії додали валідацію граничних значень, в іншій — змінили формат виведення. Через кілька місяців стає неможливо зрозуміти, яка версія «правильна», і проєкт втрачає консистентність поведінки.

Третя небезпека — збільшення обсягу тестів. Кожна копіпаста потребує своїх тестів. Якщо спільну логіку винести в єдину функцію, її можна покрити одними тестами та перевикористати. При дублюванні кожну копію доводиться тестувати окремо — це багаторазово збільшує час прогону CI та обсяг підтримуваної тестової бази.

Четверта небезпека — ілюзія продуктивності. Копіпаста створює хибне відчуття швидкості: розробник швидко вставляє код і бачить, що екран працює. Але ця «швидкість» конвертується в технічний борг, який доведеться віддавати з відсотками, коли в дубльованому блоці знайдеться баг або знадобиться зміна бізнес-логіки.

Чому розробники копіюють код

Розуміння причин копіпасти допомагає вибудувати правильну профілактику. Найчастіше розробники копіюють код не з лінощів, а через тиск дедлайнів, брак знань або незручну архітектуру.

Перша причина — дедлайни. Коли потрібно зробити екран за два дні, а схожий екран уже реалізовано, розробник копіює його цілком і змінює тільки те, що бачить користувач. На рефакторинг із виділенням спільного компонента немає часу — замовник вимагає результат. У результаті з'являється другий екран із 80 відсотками спільного коду, але з незалежною історією правок.

Друга причина — відсутність єдиної абстракції. Якщо в проєкті немає спільного компонента для типового завдання (наприклад, екрана списку з pull-to-refresh), кожен розробник писатиме свою реалізацію або копіюватиме сусідню. Архітектурні рішення, ухвалені на старті проєкту, безпосередньо впливають на кількість майбутньої копіпасти.

Третя причина — страх зламати робочий код. Розробник знає, що наявний модуль працює. Рефакторинг із виділенням спільного коду може зачепити наявну функціональність. Якщо тестове покриття низьке, ризик поломки перевищує perceived benefit від рефакторингу, і розробник обирає безпечний шлях — копіювання.

Усувайте причини, а не симптоми. Скорочення дедлайнів і впровадження code review не вирішать проблему, якщо в проєкті немає спільної архітектурної бази. Інвестуйте час у створення перевикористовуваних компонентів на ранніх етапах — це єдиний спосіб знизити спокусу копіпасти в майбутньому.

Інструменти виявлення дублікатів

Пошук копіпасти виконується автоматичними аналізаторами, які порівнюють фрагменти коду та визначають збіги вище заданого порогу. Найкращі інструменти працюють на рівні AST (абстрактного синтаксичного дерева) та ігнорують форматування, імена змінних і коментарі.

PMD CPD (Copy-Paste Detector) — найпоширеніший інструмент для Java, Kotlin, Swift, JavaScript, Python і C++. CPD аналізує токени вихідного коду та знаходить дублікати довші за задане мінімальне число токенів (за замовчуванням 100). Налаштування порогу — ключ до якісного результату: занадто низький поріг дає багато хибних спрацьовувань (спільні патерни на кшталт import), занадто високий — пропускає реальні дублікати.

Запуск PMD CPD через 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 вбудовує детектор дублікатів прямо в Quality Gate. Правило Duplicated Blocks (%) показує частку дубльованого коду. Поріг у 5 відсотків вважається здоровим для комерційних проєктів. Перевищення блокує promotion у релізну гілку. SonarQube додатково групує дублікати за типом: точні копії (exact match) і структурні копії (із зміненими іменами).

Для JavaScript і TypeScript дублікати шукають ESLint із плагіном eslint-plugin-sonarjs (правило no-duplicate-string) та утиліта jscpd, яка підтримує 150+ мов. jscpd особливо зручний для монорепозиторіїв: він знаходить дублікати між пакетами, а не тільки всередині одного модуля.

Стратегії рефакторингу дубльованого коду

Рефакторинг копіпасти зводиться до одного принципу: виділити спільне та параметризувати відмінності. Конкретний прийом залежить від обсягу дублювання та контексту.

Найпростіший випадок — дублювання в одному класі (наприклад, два методи з однаковою логікою, але різними типами). Рішення — узагальнити через дженерики або перевикористати метод із параметром-типом. Якщо дублювання охоплює кілька класів — винести спільний код в утилітний клас або extension-функцію.

Складніший випадок — дублювання на рівні екранів або модулів. Тут просте виділення функції не допомагає, тому що дублюється структура UI, логіка життєвого циклу та прив'язка даних. Рішення — створити спільний базовий клас екрана або композитний View-компонент, а відмінності передавати через параметри або протокол.

// before - two copies of the same UITableViewController
class UserListController: UITableViewController {
    private let viewModel = UserListViewModel()
    // 40 lines of code
}

class ProductListController: UITableViewController {
    private let viewModel = ProductListViewModel()
    // same 40 lines but with Product instead of User
}

// after - generic base class shared
class ListViewController<T: ListViewModel>: UITableViewController {
    let viewModel: T
    // 40 lines of code - once only

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

Найскладніший випадок — дублювання між мікросервісами або бібліотеками. Виділення спільного коду може призвести до циклічних залежностей або невиправданого зв'язування. У таких випадках копіпаста може бути усвідомленим рішенням: дві команди підтримують незалежні сервіси, і спільна бібліотека створює більше проблем, ніж вирішує. Головне — документувати таке рішення та регулярно перевіряти, чи не розійшлися копії настільки, що пора уніфікувати.

Профілактика копіпасти на рівні команди

Профілактика копіпасти ефективніша, ніж рефакторинг уже задубльованого коду. Основні заходи профілактики лежать в організації процесу розробки, а не в технологіях.

Перший захід — code review із акцентом на дублювання. Чек-лист рев'ю має включати пункт: «Чи немає в цьому PR коду, який уже існує в проєкті?». Якщо рецензент бачить копіпасту — він блокує мерж до виділення спільного компонента. Ця вимога має бути закріплена в Definition of Done команди.

Другий захід — спільна бібліотека компонентів. Кожен UI-патерн, який зустрічається на двох і більше екранах, має бути винесений у спільний модуль. Створіть shared-модуль у проєкті та зробіть його обов'язковою точкою входу для всіх UI-компонентів. Якщо компонента немає — її спочатку створюють, а вже потім використовують на екрані.

Третій захід — автоматизація в CI/CD. Додайте в пайплайн крок із перевіркою дубльованого коду (PMD CPD, jscpd, SonarQube). Перевищення порогу — помилка збірки. Розробник не може влити PR, який збільшує частку копіпасти понад допустимий рівень. Це зміщує відповідальність із code review на автоматику та гарантує, що жоден дублікат не буде пропущений.

Впроваджуйте культуру «одна реалізація — одне місце». Якщо ви бачите можливість перевикористання — не відкладайте рефакторинг на потім. Кожна копіпаста, залишена «на потім», множиться та перетворюється на некерований технічний борг.