Patay na code at zombie code sa pag-develop: ano ito, mga sanhi at paghahanap

Ano ang patay na code?

Patay na code (dead code) — source code na kasama sa programa, ngunit hindi kailanman naisakatuparan sa anumang sitwasyon ng paggamit. Pinoproseso ito ng compiler o interpreter, ngunit sa runtime, ang kontrol ay hindi kailanman pumupunta sa mga bahaging ito.

Mga klasikong halimbawa ng patay na code: mga variable na may assigned value ngunit hindi kailanman binabasa; mga function o method na hindi tinatawag kahit saan; mga branch ng condition na hindi kailanman nagiging totoo (if(false)); mga loop na ang katawan ay hindi naisakatuparan kahit isang beses.

Ayon sa ulat ng SonarQube State of Code Quality (2025), humigit-kumulang 15 porsyento ng lahat ng babala sa komersyal na Java project ay nauugnay sa hindi nagamit na private method at field. Sa JavaScript project, ang bahagi ng hindi nagamit na code ay maaaring umabot ng 30 porsyento dahil sa dinamikong kalikasan ng wika at dami ng third-party na library.

Regular na suriin ang proyekto para sa patay na code — lalo na pagkatapos ng malalaking refactoring at pagtanggal ng feature. Isang nakalimutang import o hindi nagamit na function ngayon ay maaaring maging zombie code bukas na naliligaw sa mga bagong miyembro ng team.

Mga pagkakaiba sa pagitan ng patay na code at zombie code

Zombie code (zombie code) — isang espesyal na kaso ng patay na code na nakikilala sa pamamagitan ng historikal na konteksto. Ang zombie code ay dating gumana, ngunit pagkatapos ng mga pagbabago sa sistema ay naging hindi maabot, kahit na hindi ito tinanggal, kundi iniwan “kung sakali”.

Ang pagkakaiba sa pagitan ng patay na code at zombie code ay nasa pinagmulan. Ang patay na code ay maaaring naisulat nang hindi sinasadya (hindi kailanman gumana), habang ang zombie code ay dating buhay na code na nawalan ng kaugnayan sa panahon ng refactoring. Halimbawa, isang function ng pagkalkula ng diskwento batay sa lumang business logic na pinalitan ng bago, ngunit ang lumang method ay hindi tinanggal — kung sakaling kailanganing ibalik.

Ang pangunahing panganib ng zombie code ay ang ilusyon ng gumaganang functionality. Ang isang bagong developer ay nakakakita ng function, binabasa ang dokumentasyon nito, inaakala na ito ay tinatawag sa isang lugar — at nag-aaksaya ng oras sa pag-aaral ng artifact. Kapag sinubukang tawagan ito nang direkta, maaaring lumabas na nakadepende ito sa mga tinanggal na entity o lumang API.

Sundan ang zombie code sa pamamagitan ng kasaysayan ng git: kung ang isang function ay hindi nagbago sa loob ng dalawang taon at hindi ginagamit — ito ay zombie. Tanggalin ito nang walang pag-aalinlangan, dahil ang git ay nag-iingat ng kasaysayan at kung kinakailangan, ang code ay palaring maibabalik.

Mga sanhi ng paglitaw ng patay na code

Ang una at pinakakaraniwang sanhi — iterative development na may hindi kumpletong refactoring. Nagdaragdag ang team ng bagong functionality na pumapalit sa luma, ngunit hindi tinatanggal ang mga pinalit na module. Nag-iipon ang mga sprint ng ganitong “buntot” at pagkatapos ng isang taon, ang proyekto ay natatakpan ng layer ng patay na code.

Ang pangalawang sanhi — A/B testing at feature toggle. Ang mga kondisyon para sa pag-activate ng bagong feature ay maaaring maging fixed sa paglipas ng panahon (halimbawa, palaging true), ngunit ang else branch na may alternatibong lohika ay nananatili sa code. Ang mga developer ay natatakot na tanggalin ito upang hindi aksidenteng masira ang sistema kung ang toggle ay ibinalik.

Ang pangatlong sanhi — autogeneration at copy-paste. Ang mga generator ng code (IDE, template engine) ay gumagawa ng mga template na may method na hindi pinupunan o ginagamit ng developer. Ang code na kinopya mula sa ibang proyekto ay kadalasang naglalaman ng buong bloke na hindi nauugnay sa bagong konteksto.

Ang pang-apat na sanhi — takot sa pagtanggal. Sa malalaking proyekto, ang mga developer ay natatakot na tanggalin ang code dahil hindi sila sigurado na talagang hindi ito ginagamit kahit saan. Ang takot na ito ay pinalala ng mahinang sistema ng pagsubok: kung walang awtomatikong pagsusuri, ang pagtanggal ay maaaring humantong sa mga bug na matutuklasan lamang sa produksyon.

Bakit mapanganib ang patay na code

Patay na code direktang nakakaapekto sa apat na aspeto ng kalidad ng proyekto: pagganap ng compilation, laki ng artifact, cognitive load ng team, at pagiging maaasahan ng refactoring.

Pagtaas ng oras ng compilation: pinoproseso ng compiler ang mga hindi nagamit na file, sinusuri ang mga dependency, at gumagawa ng bytecode o machine code para sa mga fragment na hindi kailanman tatakbo. Sa malalaking proyekto, nagdaragdag ito ng mga minuto sa bawat build. Para sa mga interpreted na wika (JavaScript, Python), tumataas ang oras ng pag-load ng module at konsumo ng memorya.

Panganib ng bug sa pagbabago: ang developer, habang binabago ang code, ay hindi naghihinala na ang function ay ginagamit lamang sa isang patay na branch. Pagkatapos ng refactoring, ang patay na code ay humihinto sa pag-compile o nagbibigay ng mga error — ang team ay nag-aaksaya ng oras sa pag-diagnose ng problemang hindi nakakaapekto sa pagpapatakbo ng aplikasyon.

Cognitive load — ang pinakamahal na factor. Ang bawat hindi nagamit na function ay nangangailangan ng atensyon sa pagbabasa ng code. Ang developer ay gumugugol ng mental energy sa pag-unawa kung bakit umiiral ang code na ito at kung saan ito tinatawag. Ang pag-aaral ng Developer Productivity Lab (2025) ay nagpakita: ang pagtanggal ng 20 porsyento ng patay na code ay nagbabawas ng onboarding time ng average na 18 porsyento.

Tanggalin ang patay na code kaagad pagkatapos matuklasan. Ang bawat araw ng pagkaantala ay nagpapataas ng posibilidad na ang isang tao mula sa team ay gumugol ng oras sa pag-aaral ng artifact na dapat ay tinanggal kahapon.

Mga tool sa paghahanap ng patay na code

Ang paghahanap ng patay na code ay ginagawa sa pamamagitan ng dalawang pangunahing pamamaraan: static analysis (nang hindi pinapatakbo ang programa) at dynamic analysis (profiling ng coverage sa runtime). Bawat approach ay epektibo para sa iba't ibang uri ng patay na code.

Sinusuportahan ng mga static analyzer ang lahat ng sikat na programming language. Para sa Java at Kotlin — SonarQube, IntelliJ IDEA Inspections, SpotBugs. Para sa JavaScript at TypeScript — ESLint na may mga panuntunang no-unused-vars at no-unused-modules. Para sa Swift — SwiftLint na may panuntunang unused_declaration. Para sa Python — pylint na may opsyon na unused-import at vulture para sa malalim na paghahanap.

Halimbawa ng paghahanap sa Kotlin sa pamamagitan ng ProGuard

// build.gradle.kts — configuration ng ProGuard para sa Android
android {
    buildTypes {
        release {
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
}

// proguard-rules.pro — panatilihin lamang ang mga kinakailangang class
-keep class com.example.app.** { *; }
-assumenosideeffects class Timber {
    static <methods>;
}

Hindi lang tinatanggal ng ProGuard ang mga hindi nagamit na class at method, kundi mina-minify din ang mga pangalan sa release build. Ang build na may naka-enable na ProGuard ay awtomatikong nagpapakita kung aling mga class at method ang itinuturing na hindi nagamit — sa ulat na usage.txt ay nakalista ang lahat ng tinanggal na code.

Dynamic analysis sa pamamagitan ng test coverage

Ang mga tool sa code coverage (JaCoCo para sa Java, XCTest coverage para sa Swift, Istanbul para sa JavaScript) ay nagpapakita kung aling mga linya at branch ang naisakatuparan sa panahon ng pagsubok. Ang mga method na may zero coverage ay kandidato para sa patay na code. Gayunpaman, ang kawalan ng coverage ay hindi ginagarantiya na ang code ay hindi tinatawag sa produksyon — para sa buong katiyakan, gamitin ang kombinasyon ng static at dynamic na analysis.

I-configure ang CI pipeline upang ang build ay mabigo kapag lumampas sa threshold ng hindi nagamit na deklarasyon. Ang SonarQube Quality Gate na may panuntunang “Proporsyon ng hindi nagamit na private code na hindi hihigit sa 3%” ay pumipigil sa akumulasyon ng patay na code sa antas ng proseso ng pag-develop.

Paano ligtas na tanggalin ang patay na code

Ang proseso ng pagtanggal ng patay na code ay binubuo ng apat na hakbang: hanapin, suriin, tanggalin, suriin muli. Ang paglaktaw sa anumang hakbang ay nagpapataas ng panganib ng regression.

Unang hakbang — maghanap ng mga kandidato sa pamamagitan ng static analyzer. Kumuha ng ulat tungkol sa hindi nagamit na mga deklarasyon: function, class, variable, import. I-filter ang false positives — ang mga analyzer ay minsan nagkakamali sa reflection, dynamic loading ng class, o hidden na tawag sa pamamagitan ng serialization.

Ikalawang hakbang — suriin sa pamamagitan ng git blame at kasaysayan ng pagbabago. Tingnan kung kailan at bakit isinulat ang code. Kung ang code ay bahagi ng feature na na-disable ng feature toggle, siguraduhin na ang toggle ay naka-fixed at hindi na muling i-activate. I-comment ang code na alinlangan mong tanggalin at mag-iwan ng TODO na may ticket para sa muling pagsusuri pagkatapos ng isang buwan.

Ikatlong hakbang — tanggalin sa isang hiwalay na branch na may pagpapatakbo ng kumpletong hanay ng mga test. Kung pumasa ang mga test — mababa ang posibilidad ng regression. Kung nabigo ang mga test — nangangahulugan na ginagamit pa rin ang code at kailangang alamin kung saang sitwasyon.

// bago — patay na code at zombie code sa parehong file
int calculateV1(int price) { // hindi tinatawag kahit saan
    int tax = price * 0.18;
    return price + tax;
}

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

// pagkatapos — patay na code tinanggal, zombie code nalinis
int calculatePrice(int price, double rate) {
    return static_cast<int>(price * (1 + rate));
}

Ikaapat na hakbang — code review ng mga pagbabago. Dapat kumpirmahin ng reviewer na ang code ay talagang patay na. Kung hindi sigurado ang reviewer — mag-iwan ng komento sa code at ipagpaliban ang pagtanggal hanggang sa kumpletong pagsusuri. Pagkatapos i-merge ang branch, tanggalin ang branch upang hindi dumami ang zombie code sa git repository.

Magpatupad ng patakaran: walang pull request ang dapat maglaman ng bagong patay na code. Magdagdag ng linter sa pre-commit hooks na humaharang sa commit kung may hindi nagamit na variable o import. Ang pag-iwas ay palaging mas mura kaysa paglilinis.