Джанк у розробці — що це, чим шкідливий junk-код і як прибирати

Що таке джанк?

Джанк (junk code) — збірний термін для коду, конфігурацій і залежностей, які присутні в проєкті, але не несуть функціональної цінності. Джанк не обов'язково зламаний або невикористовуваний — проблема в тому, що його наявність погіршує метрики проєкту без адекватного виправдання.

Джанк ділиться на чотири категорії. Перша — надмірні залежності: бібліотеки, підключені для однієї функції, яку можна реалізувати стандартними засобами. Друга — мертвий вантаж: закоментовані блоки, TODO без тікетів, порожні методи та класи-заглушки. Третя — дублюючі рішення: дві бібліотеки, що роблять одне й те саме (наприклад, Gson і Kotlin Serialization в одному проєкті). Четверта — овер-інжиніринг: архітектурні прошарки, які не використовуються, але підтримуються «на майбутнє».

За даними дослідження Stripe Engineering Productivity (2025), видалення 10 відсотків джанку з типового проєкту скорочує час повної збірки в середньому на 22 відсотки. Причина: кожна зайва залежність збільшує граф збірки, кожна порожня абстракція потребує часу на розуміння, кожен закоментований блок відволікає увагу.

Головна складність у боротьбі з джанком — відсутність негайних наслідків. Проєкт із junk-кодом компілюється та працює. Проблеми накопичуються поступово: збірка сповільнюється, кількість transitive dependencies зростає, а через рік додати нову фічу стає вдвічі довше, ніж має бути.

Junk-залежності та як їх виявляти

Junk-залежності — це бібліотеки та пакети, які підключені до проєкту, але не використовуються безпосередньо в коді, або використовуються лише в одній функції, яку простіше реалізувати на стандартних API.

Типові приклади: бібліотека для роботи з JSON, коли проєкт уже використовує Kotlin Serialization (два парсери — це джанк); бібліотека Apache Commons Lang для одного методу StringUtils.isEmpty, який замінюється Kotlin extension isNullOrBlank; бібліотека для DI, яка використовується в одному модулі з десяти, а інші отримують залежності через конструктор вручну.

Кожна зайва залежність — це не лише зайвий код у бінарнику. Це збільшення surface area для вразливостей: за даними GitHub Advisory Database (2025), 40 відсотків критичних CVE у мобільних проєктах припадають на транзитивні залежності, які розробники не контролюють. Чим менше залежностей — тим менше поверхня атаки.

Аналіз залежностей Android-проєкту

// View Gradle dependency tree
./gradlew app:dependencies --configuration releaseRuntimeClasspath

// Find unused dependencies (Gradle plugin)
plugins {
    id "com.autonomousapps.dependency-analysis" version "2.0.0"
}

// Generate unused library report
./gradlew buildHealth

Для iOS використовуйте команду swift package show-dependencies, яка виводить повне дерево залежностей. Інструмент Xcode Build Timeline показує, скільки часу кожна бібліотека додає до збірки. Якщо бібліотека займає 30 відсотків часу компіляції, але використовується в одному екрані — це кандидат на видалення або заміну.

Для Node.js (React Native) використовуйте depcheck — утиліту, яка знаходить невикористовувані залежності в package.json, і npm-check, яка додатково показує застарілі версії. Впровадьте правило: кожна нова залежність проходить code review з обґрунтуванням «чому не можна стандартними засобами».

Мертві імпорти та закоментований код

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

Сучасні IDE автоматично підсвічують невикористовувані імпорти сірим кольором. Налаштуйте авто-очищення на збереження файлу: в IntelliJ IDEA — Optimize Imports on the fly, в Xcode — Editor > Remove Unused Imports. У CI додайте перевірку: лінтер має блокувати коміти з невикористовуваними імпортами.

Закоментований код — ще один вид джанку. Розробники коментують блоки, щоб «не втратити» функціональність при рефакторингу. Однак git зберігає повну історію змін: будь-який видалений код можна відновити за одну команду git revert або git log -S . Закоментований код у master — це неповага до команди: кожен розробник витрачає розумову енергію на питання «а навіщо це закоментовано і коли треба розкоментувати».

Правило: у репозиторії немає закоментованого коду. Якщо код не потрібен — видаліть його назавжди. Якщо код потрібен, але тимчасово вимкнений — використовуйте feature toggle з тікетом і терміном. Коментарі виду // TODO: remove after migration — не залишайте без дедлайну. Поставте дату й нагадайте собі календарем.

Надмірні абстракції та овер-інжиніринг

Овер-інжиніринг — створення архітектурних прошарків, які не вирішують поточних проблем, але потребують підтримки. Це один із найскладніших видів джанку, тому що формально код «правильний»: він слідує SOLID, покритий тестами та відповідає архітектурі. Проблема в тому, що він не потрібен.

Класичний приклад — абстрактний клас UseCase з одним методом invoke, який просто викликає репозиторій. Якщо UseCase не додає логіки (кешування, retry, трансформація), а тільки передає виклик далі — це зайва сутність. Вона збільшує навігацію по проєкту: розробник відкриває UseCase, дивиться, що там invoke → repository — і закриває. Час витрачено, користі нуль.

Інший приклад — надмірна параметризація. Generic-інтерфейс із шістьма type parameters, який використовується в одному місці. Кожен type parameter — це когнітивне навантаження: при читанні коду потрібно тримати в голові шість типів, хоча реально використовуються лише два. Якщо абстракція не перевикористовується — вона надмірна.

Критерій відсікання: якщо абстракція не перевикористовується в трьох різних контекстах — видаляйте її. Абстракція виправдана, коли вона реально вирішує проблему дублювання, а не прогнозує гіпотетичні сценарії майбутнього. YAGNI (You Ain't Gonna Need It) — найкращий принцип профілактики овер-інжинірингу.

Інструменти аудиту джанку

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

Для повноцінного аудиту запускайте buildHealth (Android) або depcheck (Node.js) раз на спринт. Створіть дашборд у CI, який показує динаміку кількості залежностей по спринтах. Якщо кількість зростає, а функціональність не зростає пропорційно — команда накопичує джанк.

Зверніть увагу на duplicate classes — помилку, коли дві бібліотеки містять один і той же клас. Це не лише джанк, а й пряме джерело конфліктів збірки. У Gradle такі конфлікти вирішуються через force або exclude, але кожне таке вирішення — сигнал, що одна з бібліотек зайва.

Процес регулярного чищення проєкту

Чищення джанку — це не разова акція, а регулярний процес. Без регламенту джанк повертається протягом двох-трьох спринтів. Найкраща практика — виділяти 10–15 відсотків ємності кожного спринту на технічне чищення, включаючи аудит джанку.

Процес складається з чотирьох кроків. Перший — діагностика: запуск інструментів, отримання звіту, пріоритизація. Високий пріоритет — залежності з відомими CVE та дублюючі бібліотеки. Середній — мертві імпорти та закоментований код. Низький — надмірні абстракції (потребують ручного аналізу).

Другий — чищення: видалення мертвих залежностей, заміна дублюючих бібліотек на одну, видалення закоментованого коду. Кожна зміна робиться окремим комітом зі зрозумілим message: «remove unused dependency: gson (replaced by kotlinx.serialization)», «delete commented code in LoginViewModel».

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

Четвертий — профілактика: оновлення чек-листа code review, додавання правила «жодної нової залежності без обґрунтування» в Definition of Done, налаштування автоматичної перевірки в CI. Профілактика — єдиний спосіб не допустити повторного накопичення джанку.