Мртав код и зомби код у развоју: шта је то, узроци и претрага

Шта је мртав код?

Мртав код (dead code) — изворни код који је укључен у програм, али се никада не извршава у било ком сценарију коришћења. Компајлер или интерпретер га обрађује, али у време извршавања контрола никада не стиже до ових делова.

Класични примери мртвог кода: променљиве којима је додељена вредност, али се никада не читају; функције или методе које се нигде не позивају; гране услова које никада не постају истините (if(false)); петље чије се тело не извршава ни једном.

Према извештају SonarQube State of Code Quality (2025), око 15 одсто свих упозорења у комерцијалним Java пројектима односи се на неискоришћене private методе и поља. У JavaScript пројектима удео неискоришћеног кода може достићи 30 одсто због динамичке природе језика и обиља библиотека трећих страна.

Редовно проверавајте пројекат на присуство мртвог кода — посебно након великих рефакторисања и уклањања функционалности. Један заборављени import или неискоришћена функција данас сутра се може претворити у зомби код који доводи у заблуду нове чланове тима.

Разлике између мртвог кода и зомби кода

Зомби код (zombie code) — посебан случај мртвог кода који се издваја по историјском контексту. Зомби код је некада радио, али је након промена у систему престао да буде достижан, иако га нису обрисали, већ су га оставили „за сваки случај".

Разлика између мртвог кода и зомби кода је у пореклу. Мртав код је могао бити написан грешком (никада није радио), док је зомби код некада живи код који је изгубио актуелност током рефакторисања. На пример, функција за израчунавање попуста по старој пословној логици коју је заменила нова, али стари метод нису обрисали — у случају да буде потребно вратити га.

Главна опасност зомби кода је илузија функционишућег система. Нови програмер види функцију, чита њену документацију, претпоставља да се негде позива — и троши време на проучавање артефакта. При покушају директног позивања може се испоставити да зависи од обрисаних entities или застарелих API-ја.

Пратите зомби код кроз историју git-а: ако се функција није мењала две године и не користи се — то је зомби. Уклоните га без оклевања, јер git чува историју и по потреби код се увек може вратити.

Узроци појаве мртвог кода

Први и најчешћи узрок — итеративни развој са непотпуним рефакторисањем. Тим додаје нову функционалност која замењује стару, али не уклања замењене модуле. Спринтови акумулирају такве „репове" и након годину дана пројекат обраста слојем мртвог кода.

Други узрок — A/B тестирање и feature toggle. Услови за укључивање нове функционалности могу се временом фиксирати (на пример, увек true), али else грана са алтернативном логиком остаје у коду. Програмери се плаше да је уклоне како не би случајно покварили систем ако се toggle пребаци назад.

Трећи узрок — аутоматско генерисање и copy-paste. Генератори кода (IDE, шаблонизатори) креирају шаблоне са методама које програмер не попуњава или не користи. Код копиран из другог пројекта често садржи читаве блокове који нису релевантни за нови контекст.

Четврти узрок — страх од брисања. У великим пројектима програмери се плаше да обришу код јер нису сигурни да се заиста нигде не користи. Овај страх се појачава слабим системом тестова: ако нема аутоматске провере, брисање може довести до грешака које ће бити откривене тек у продакцији.

Зашто је мртав код опасан

Мртав код директно утиче на четири аспекта квалитета пројекта: перформансе компајлирања, величину артефакта, когнитивно оптерећење тима и поузданост рефакторисања.

Повећање времена компајлирања: компајлер обрађује неискоришћене фајлове, анализира зависности и генерише бајткод или машински код за фрагменте који никада неће бити покренути. У великим пројектима ово додаје минуте сваком компајлирању. За интерпретиране језике (JavaScript, Python) расте време учитавања модула и потрошња меморије.

Ризик од грешака при модификацији: програмер, мењајући код, не сумња да се функција користи само у мртвој грани. Након рефакторисања мртав код престаје да се компајлира или даје грешке — тим троши време на дијагностиковање проблема који не утиче на рад апликације.

Когнитивно оптерећење — најскупљи фактор. Свака неискоришћена функција захтева пажњу при читању кода. Програмер троши менталну енергију на разумевање зашто тај код постоји и где се позива. Истраживање Developer Productivity Lab (2025) показало је: уклањање 20 одсто мртвог кода смањује време укључивања (onboarding time) у просеку за 18 одсто.

Уклоните мртав код одмах по откривању. Сваки дан одлагања повећава вероватноћу да неко из тима потроши сате на проучавање артефакта који је требало уклонити јуче.

Алати за проналажење мртвог кода

Проналажење мртвог кода обавља се двема главним методама: статичка анализа (без покретања програма) и динамичка анализа (профилисање покривености у време извршавања). Сваки приступ је ефикасан за различите врсте мртвог кода.

Статички анализатори подржавају све популарне програмске језике. За Java и Kotlin — SonarQube, IntelliJ IDEA Inspections, SpotBugs. За JavaScript и TypeScript — ESLint са правилима no-unused-vars и no-unused-modules. За Swift — SwiftLint са правилом unused_declaration. За Python — pylint са опцијом unused-import и vulture за дубинско претраживање.

Пример претраге у Kotlin-у преко ProGuard-а

// build.gradle.kts — ProGuard конфигурација за Android
android {
    buildTypes {
        release {
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
}

// proguard-rules.pro — задржи само потребне класе
-keep class com.example.app.** { *; }
-assumenosideeffects class Timber {
    static <methods>;
}

ProGuard не само да уклања неискоришћене класе и методе, већ и минификује имена у release компајлирању. Компајлирање са укљученим ProGuard-ом аутоматски показује које класе и методе се сматрају неискоришћеним — у извештају usage.txt наведен је сав уклоњени код.

Динамичка анализа кроз покривеност тестовима

Алати за покривеност кода (JaCoCo за Java, XCTest coverage за Swift, Istanbul за JavaScript) показују које линије и гране се извршавају током тестова. Методе са нултом покривеношћу су кандидати за мртав код. Међутим, недостатак покривености не гарантује да се код не позива у продакцији — за потпуну сигурност користите комбинацију статичке и динамичке анализе.

Подесите CI pipeline тако да компајлирање пада када се прекорачи праг неискоришћених декларација. SonarQube Quality Gate са правилом „Удео неискоришћеног private кода не већи од 3%" спречава нагомилавање мртвог кода на нивоу развојног процеса.

Како безбедно уклонити мртав код

Процес уклањања мртвог кода састоји се од четири корака: пронађи, провери, уклони, поново провери. Пропуштање било ког корака повећава ризик од регресије.

Први корак — проналажење кандидата преко статичког анализатора. Добијте извештај о неискоришћеним декларацијама: функцијама, класама, променљивама, импортима. Филтрирајте лажно позитивне резултате — анализатори понекад греше код рефлексије, динамичког учитавања класа или скривених позива кроз серијализацију.

Други корак — провера кроз git blame и историју измена. Погледајте када и зашто је код написан. Ако је код био део функционалности искључене feature toggle-ом, уверите се да је toggle фиксиран и да неће бити поново укључен. Коментаришите код који оклевате да уклоните и оставите TODO са задатком за поновну проверу за месец дана.

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

// пре — мртав код и зомби код у истом фајлу
int calculateV1(int price) { // нигде се не позива
    int tax = price * 0.18;
    return price + tax;
}

int calculateV2(int price, double rate) {
    return static_cast<int>(price * (1 + rate));
}

// после — мртав код уклоњен, зомби код очишћен
int calculatePrice(int price, double rate) {
    return static_cast<int>(price * (1 + rate));
}

Четврти корак — code review измена. Рецензент мора потврдити да је код заиста мртав. Ако рецензент није сигуран — оставите коментар у коду и одложите уклањање до потпуне анализе. Након спајања гране, обришите грану да не бисте множили зомби код у git репозиторијуму.

Уведите правило: ниједан pull request не сме да садржи нови мртав код. Додајте линтер у pre-commit hook-ове који блокира комит када постоје неискоришћене променљиве или импорти. Превенција је увек јефтинија од чишћења.