Джанк в разработката — какво е, защо junk-кодът е вреден и как да го премахваме

Какво е джанк?

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

Джанкът се дели на четири категории. Първа — излишни зависимости: библиотеки, добавени за една функция, която може да се реализира със стандартни средства. Втора — мъртъв товар: коментирани блокове, TODO без билети, празни методи и класове-заглушки. Трета — дублиращи се решения: две библиотеки, които правят едно и също нещо (например Gson и Kotlin Serialization в един проект). Четвърта — over-engineering: архитектурни слоеве, които не се използват, но се поддържат за в бъдеще.

Според изследване на Stripe Engineering Productivity (2025), премахването на 10 процента джанк от типичен проект намалява времето за пълно изграждане средно с 22 процента. Причина: всяка допълнителна зависимост увеличава графа за изграждане, всяка празна абстракция изисква време за разбиране, всеки коментиран блок отклонява вниманието.

Основната трудност в борбата с джанка е липсата на незабавни последици. Проект с junk-код се компилира и работи. Проблемите се натрупват постепенно: изграждането се забавя, броят на транзитивните зависимости расте, а след една година добавянето на нова функция отнема два пъти повече време, отколкото трябва.

Junk-зависимости и как да ги идентифицираме

Junk-зависимости — това са библиотеки и пакети, които са свързани към проекта, но не се използват директно в кода, или се използват само в една функция, която може по-лесно да се реализира със стандартни API-та.

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

Всяка допълнителна зависимост не е само допълнителен код в бинарния файл. Това е и увеличаване на повърхността за атака за уязвимости: според GitHub Advisory Database (2025), 40 процента от критичните CVE в мобилни проекти идват от транзитивни зависимости, които разработчиците не контролират. Колкото по-малко зависимости — толкова по-малка повърхност за атака.

Анализ на зависимостите на Android проект

// Преглед на Gradle дървото на зависимостите
./gradlew app:dependencies --configuration releaseRuntimeClasspath

// Намиране на неизползвани зависимости (Gradle плъгин)
plugins {
    id "com.autonomousapps.dependency-analysis" version "2.0.0"
}

// Генериране на доклад за неизползвани библиотеки
./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 — не ги оставяйте без срок. Поставете дата и задайте напомняне в календара.

Излишни абстракции и over-engineering

Over-engineering — създаване на архитектурни слоеве, които не решават текущи проблеми, но изискват поддръжка. Това е един от най-трудните видове джанк, защото формално кодът е правилен: следва SOLID, покрит е с тестове и съответства на архитектурата. Проблемът е, че не е необходим.

Класически пример — абстрактен клас UseCase с един метод invoke, който просто извиква хранилището. Ако UseCase не добавя логика (кеширане, retry, трансформация), а само препредава повикването — това е излишна същност. Увеличава навигацията в проекта: разработчикът отваря UseCase, вижда invoke → repository — и затваря. Време загубено, полза нула.

Друг пример — излишна параметризация. Родов интерфейс с шест параметъра на типа, използван на едно място. Всеки параметър на типа е когнитивно натоварване: при четене на кода трябва да държите шест типа в ума си, въпреки че реално се използват само два. Ако абстракцията не се преизползва — тя е излишна.

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

Инструменти за одит на джанк

Одитът на джанк изисква комбинация от статичен анализ, анализ на зависимости и ръчна проверка. Пълното автоматизиране на търсенето на излишни абстракции не е възможно, но техническият джанк (мъртви импорти, неизползвани библиотеки, коментиран код) се намира с инструменти.

За пълен одит стартирайте buildHealth (Android) или depcheck (Node.js) веднъж на спринт. Създайте табло в CI, което показва динамиката на броя зависимости в спринтовете. Ако броят расте, а функционалността не расте пропорционално — екипът натрупва джанк.

Обърнете внимание на duplicate classes — грешка, когато две библиотеки съдържат един и същ клас. Това не е само джанк, но и пряк източник на конфликти при изграждане. В Gradle такива конфликти се разрешават чрез force или exclude, но всяко такова разрешаване е сигнал, че една от библиотеките е излишна.

Процес на редовно почистване на проекта

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

Процесът се състои от четири стъпки. Първа — диагностика: стартиране на инструменти, получаване на доклад, приоритизиране. Висок приоритет — зависимости с известни CVE и дублиращи се библиотеки. Среден — мъртви импорти и коментиран код. Нисък — излишни абстракции (изискват ръчен анализ).

Втора — почистване: премахване на мъртви зависимости, замяна на дублиращи се библиотеки с една, премахване на коментиран код. Всяка промяна се прави в отделен комит с разбираемо съобщение: remove unused dependency: gson (replaced by kotlinx.serialization), delete commented code in LoginViewModel.

Трета — верификация: изграждане на проекта, стартиране на тестове, проверка на UI. Ако след премахване на зависимост тестовете минават — зависимостта наистина не е била необходима. Ако тестовете се провалят — значи някъде е останала скрита референция, която статичният анализатор не е открил.

Четвърта — превенция: актуализиране на списъка за проверка на code review, добавяне на правилото без нова зависимост без обосновка в Definition of Done, настройване на автоматична проверка в CI. Превенцията е единственият начин да се предотврати повторното натрупване на джанк.