Junk sa pag-develop — ano ito, bakit nakakasama ang junk-code at paano ito alisin

Ano ang junk?

Junk (junk code) — isang kolektibong termino para sa code, configuration, at dependencies na nasa proyekto ngunit walang functional na halaga. Ang junk ay hindi nangangahulugang sira o hindi ginagamit — ang problema ay ang presensya nito ay nagpapalala sa metrics ng proyekto nang walang sapat na katwiran.

Ang junk ay nahahati sa apat na kategorya. Una — sobrang dependencies: mga library na idinagdag para sa isang function na maaaring ma-implement gamit ang standard na paraan. Pangalawa — patay na bigat: mga naka-comment na block, TODO na walang ticket, walang laman na method, at stub class. Pangatlo — duplicate na solusyon: dalawang library na gumagawa ng parehong bagay (halimbawa, Gson at Kotlin Serialization sa iisang proyekto). Pang-apat — over-engineering: architectural layer na hindi ginagamit ngunit pinapanatili para sa hinaharap.

Ayon sa pananaliksik ng Stripe Engineering Productivity (2025), ang pag-alis ng 10 porsyento ng junk mula sa tipikal na proyekto ay nagpapababa ng oras ng buong build ng average na 22 porsyento. Dahilan: bawat sobrang dependency ay nagpapalaki ng build graph, bawat walang laman na abstraction ay nangangailangan ng oras upang maunawaan, bawat naka-comment na block ay nakakagambala.

Ang pangunahing kahirapan sa paglaban sa junk ay ang kawalan ng agarang kahihinatnan. Ang proyekto na may junk-code ay nagco-compile at gumagana. Ang mga problema ay naipon nang paunti-unti: bumagal ang build, dumarami ang transitive dependencies, at pagkalipas ng isang taon, ang pagdagdag ng bagong feature ay tumatagal ng dalawang beses na mas matagal kaysa sa dapat.

Junk-dependencies at paano makilala ang mga ito

Junk-dependencies — ay mga library at package na nakakonekta sa proyekto ngunit hindi direktang ginagamit sa code, o ginagamit lamang sa isang function na mas madaling ma-implement gamit ang standard na API.

Mga tipikal na halimbawa: library para sa JSON kapag ang proyekto ay gumagamit na ng Kotlin Serialization (dalawang parser — iyan ay junk); library na Apache Commons Lang para sa isang StringUtils.isEmpty method, na pinalitan ng Kotlin extension na isNullOrBlank; library ng DI na ginagamit sa isa sa sampung module, habang ang iba ay manually nakakakuha ng dependencies sa pamamagitan ng constructor.

Bawat sobrang dependency ay hindi lamang extra code sa binary. Ito ay pagpapalaki ng attack surface para sa mga vulnerability: ayon sa GitHub Advisory Database (2025), 40 porsyento ng kritikal na CVE sa mobile projects ay nagmumula sa transitive dependencies na hindi kontrolado ng mga developer. Kung mas kaunti ang dependencies — mas maliit ang attack surface.

Pagsusuri ng dependencies ng Android project

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

// Hanapin ang hindi ginagamit na dependencies (Gradle plugin)
plugins {
    id "com.autonomousapps.dependency-analysis" version "2.0.0"
}

// Gumawa ng ulat ng hindi ginagamit na library
./gradlew buildHealth

Para sa iOS gamitin ang command na swift package show-dependencies, na nagpapakita ng buong dependency tree. Ang tool na Xcode Build Timeline ay nagpapakita kung gaano karaming oras ang idinadagdag ng bawat library sa build. Kung ang isang library ay kumukuha ng 30 porsyento ng oras ng compilation ngunit ginagamit sa isang screen lamang — ito ay kandidato para sa pag-alis o pagpapalit.

Para sa Node.js (React Native) gamitin ang depcheck — isang utility na nakakahanap ng hindi ginagamit na dependencies sa package.json, at npm-check, na nagpapakita rin ng mga lumang bersyon. Ipatupad ang patakaran: bawat bagong dependency ay dapat dumaan sa code review na may katwirang „bakit hindi pwedeng gamitan ng standard na paraan”.

Patay na import at naka-comment na code

Patay na import — ang pinakakaraniwang uri ng junk. Hindi ito nakakaapekto sa runtime, ngunit pinapataas ang oras ng compilation: pinoproseso ng compiler ang bawat import, kahit hindi ito ginagamit. Sa malalaking proyekto, ang pag-alis ng hindi ginagamit na import ay nagpapababa ng oras ng build ng 5–10 porsyento.

Awtomatikong hin-highlight ng mga modernong IDE ang hindi ginagamit na import sa kulay abo. I-configure ang auto-clean sa pag-save ng file: sa IntelliJ IDEA — Optimize Imports on the fly, sa Xcode — Editor > Remove Unused Imports. Sa CI magdagdag ng tseke: dapat i-block ng linter ang mga commit na may hindi ginagamit na import.

Naka-comment na code — isa pang uri ng junk. Nagko-comment ang mga developer ng mga block para hindi mawala ang functionality sa panahon ng refactoring. Ngunit ang git ay nag-iimbak ng buong kasaysayan ng mga pagbabago: ang anumang tinanggal na code ay maaaring maibalik gamit ang isang command na git revert o git log -S . Ang naka-comment na code sa master ay kawalan ng respeto sa team: bawat developer ay gumugugol ng mental energy sa tanong na „bakit ito naka-comment at kailan ito dapat i-uncomment”.

Patakaran: walang naka-comment na code sa repository. Kung hindi kailangan ang code — tanggalin ito nang permanente. Kung kailangan ang code ngunit pansamantalang naka-disable — gumamit ng feature toggle na may ticket at deadline. Ang mga komento tulad ng // TODO: remove after migration — huwag iwanan nang walang deadline. Maglagay ng petsa at magtakda ng paalala sa kalendaryo.

Sobrang abstraction at over-engineering

Over-engineering — paglikha ng architectural layer na hindi lumulutas ng kasalukuyang problema ngunit nangangailangan ng maintenance. Ito ay isa sa pinakamahirap na uri ng junk dahil pormal na ang code ay tama: sumusunod sa SOLID, may test coverage, at naaayon sa architecture. Ang problema ay hindi ito kailangan.

Ang klasikong halimbawa — isang abstract na UseCase class na may isang invoke method na tumatawag lamang sa repository. Kung ang UseCase ay hindi nagdadagdag ng logic (caching, retry, transformation), at ipinapasa lamang ang tawag — ito ay isang sobrang entity. Pinapataas nito ang navigation sa proyekto: binuksan ng developer ang UseCase, nakita invoke → repository — at isinara. Nasayang ang oras, sero ang benepisyo.

Isa pang halimbawa — sobrang parameterization. Isang generic interface na may anim na type parameter, ginagamit sa isang lugar. Bawat type parameter ay cognitive load: kapag binabasa ang code, kailangan mong tandaan ang anim na uri, kahit dalawa lang ang aktwal na ginagamit. Kung ang abstraction ay hindi ginagamit muli — ito ay sobra.

Ang cut-off criterion: kung ang abstraction ay hindi ginagamit muli sa tatlong magkakaibang konteksto — tanggalin ito. Ang abstraction ay makatwiran kapag ito ay aktwal na lumulutas ng problema ng pagdodoble, hindi kapag naghuhula ng hypothetical na senaryo sa hinaharap. YAGNI (You Ain't Gonna Need It) — ang pinakamahusay na prinsipyo ng pag-iwas sa over-engineering.

Mga tool sa audit ng junk

Ang audit ng junk ay nangangailangan ng kumbinasyon ng static analysis, dependency analysis, at manual na pagsusuri. Hindi ganap na ma-automate ang paghahanap ng sobrang abstraction, ngunit ang technical junk (patay na import, hindi ginagamit na library, naka-comment na code) ay matatagpuan gamit ang mga tool.

Para sa kumpletong audit, patakbuhin ang buildHealth (Android) o depcheck (Node.js) isang beses kada sprint. Gumawa ng dashboard sa CI na nagpapakita ng dynamics ng bilang ng dependencies sa bawat sprint. Kung ang bilang ay tumataas ngunit ang functionality ay hindi tumataas nang proporsyonal — ang team ay nag-iipon ng junk.

Bigyang pansin ang duplicate classes — isang error kapag ang dalawang library ay naglalaman ng parehong class. Ito ay hindi lamang junk, kundi direktang source ng build conflict. Sa Gradle, ang mga ganitong conflict ay nareresolba sa pamamagitan ng force o exclude, ngunit bawat ganoong resolba ay senyales na ang isa sa mga library ay sobra.

Proseso ng regular na paglilinis ng proyekto

Ang paglilinis ng junk ay hindi isang beses na aksyon, kundi isang regular na proseso. Walang regulasyon, babalik ang junk sa loob ng dalawa hanggang tatlong sprint. Ang pinakamahusay na praktika — maglaan ng 10–15 porsyento ng kapasidad ng bawat sprint para sa technical cleaning, kasama ang audit ng junk.

Ang proseso ay binubuo ng apat na hakbang. Una — diagnostic: pagpapatakbo ng mga tool, pagkuha ng ulat, pag-prioritize. Mataas na priyoridad — dependencies na may kilalang CVE at duplicate na library. Katamtaman — patay na import at naka-comment na code. Mababa — sobrang abstraction (nangangailangan ng manual analysis).

Pangalawa — paglilinis: pag-alis ng patay na dependencies, pagpapalit ng duplicate na library ng isa, pag-alis ng naka-comment na code. Bawat pagbabago ay ginagawa sa hiwalay na commit na may malinaw na mensahe: „remove unused dependency: gson (replaced by kotlinx.serialization)”, „delete commented code in LoginViewModel”.

Pangatlo — beripikasyon: pag-build ng proyekto, pagpatakbo ng mga test, pagsusuri ng UI. Kung pagkatapos alisin ang dependency ay pumasa ang mga test — ang dependency ay talagang hindi kailangan. Kung bumagsak ang mga test — nangangahulugan na may naiwang nakatagong reference na hindi na-detect ng static analyzer.

Pang-apat — pag-iwas: pag-update ng code review checklist, pagdagdag ng patakarang „walang bagong dependency nang walang katwiran” sa Definition of Done, pag-setup ng automatic check sa CI. Ang pag-iwas ay ang tanging paraan upang maiwasan ang muling pag-ipon ng junk.