Џанк у развоју — шта је то, зашто је 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 са образложењем „зашто се не може стандардним средствима“.

Мртви import-и и коментарисани код

Мртви import-и — најраспрострањенија врста џанка. Они не утичу на run-time, али повећавају време компајлације: компајлер обрађује сваки import, чак и ако се не користи. У великим пројектима уклањање неискоришћених import-а скраћује време изградње за 5–10 посто.

Модерна IDE-а аутоматски истичу неискоришћене import-е сивом бојом. Подесите аутоматско чишћење при чувању датотеке: у IntelliJ IDEA — Optimize Imports on the fly, у Xcode — Editor > Remove Unused Imports. У CI додајте проверу: lintер треба да блокира комитове са неискоришћеним import-има.

Коментарисани код — још једна врста џанка. Програмери коментаришу блокове да „не изгубе“ функционалност приликом рефакторисања. Међутим, 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 — и затвара. Време потрошено, корист нула.

Други пример — сувишна параметризација. Generic-интерфејс са шест type параметара, који се користи на једном месту. Сваки type parameter је когнитивно оптерећење: при читању кода треба држати у глави шест типова, иако се стварно користе само два. Ако се апстракција не користи поново — сувишна је.

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

Алати за ревизију џанка

Ревизија џанка захтева комбинацију статичке анализе, анализе зависности и ручне провере. Потпуно аутоматизовати претрагу сувишних апстракција се не може, али технички џанк (мртви import-и, неискоришћене библиотеке, коментарисани код) се проналази алатима.

За потпуну ревизију покрените buildHealth (Android) или depcheck (Node.js) једном по спринту. Направите dashboard у CI-ју који приказује динамику броја зависности кроз спринтове. Ако број расте, а функционалност не расте пропорционално — тим акумулира џанк.

Обратите пажњу на duplicate classes — грешку када две библиотеке садрже исту класу. То није само џанк, већ и директан извор конфликата изградње. У Gradle-у се такви конфликти решавају кроз force или exclude, али свако такво решење је сигнал да је једна од библиотека сувишна.

Процес редовног чишћења пројекта

Чишћење џанка није једнократна акција, већ редован процес. Без прописа, џанк се враћа у року од два до три спринта. Најбоља пракса — издвојити 10–15 посто капацитета сваког спринта за техничко чишћење, укључујући ревизију џанка.

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

Други — чишћење: уклањање мртвих зависности, замена дуплираних библиотека једном, уклањање коментарисаног кода. Свака измена се прави као посебан комит са разумљивим message-ом: „remove unused dependency: gson (replaced by kotlinx.serialization)“, „delete commented code in LoginViewModel“.

Трећи — верификација: изградња пројекта, покретање тестова, провера UI-ја. Ако након уклањања зависности тестови прођу — зависност заиста није била потребна. Ако тестови падну — значи да је негде остала скривена референца коју статички анализатор није открио.

Четврти — превенција: ажурирање checklist-е за code review, додавање правила „ниједна нова зависност без образложења“ у Definition of Done, подешавање аутоматске провере у CI-ју. Превенција је једини начин да се спречи поновно нагомилавање џанка.