Dependency Hell sa mga proyekto — ano ito, mga sanhi at paraan ng paglutas

Ano ang Dependency Hell sa pag-develop

Dependency Hell — terminong naglalarawan sa sitwasyon kung saan hindi malulutas ng sistema ng pamamahala ng dependency ang salungatan ng bersyon ng mga aklatan. Ang proyekto ay nangangailangan ng aklatan A bersyon 1.x at aklatan B bersyon 2.x, ngunit ang A ay nakadepende sa C bersyon 1.0 at B ay nakadepende sa C bersyon 2.0, habang ang C:1.0 at C:2.0 ay hindi tugma.

Ang problema ay katangian ng lahat ng ecosystem na may mga tagapamahala ng pakete. Sa Android — mga salungatan sa Gradle sa pagitan ng support library at AndroidX. Sa iOS — mga salungatan sa CocoaPods sa pagitan ng iba't ibang bersyon ng Alamofire. Sa Node.js — mga salungatan sa peer dependency sa npm. Sa Python — mga pagkabigo sa pagresolba sa pip.

Ang mga modernong tagapamahala ng dependency (npm v7+, Gradle 7+, SwiftPM) ay nagpabuti ng mga algorithm ng pagresolba, ngunit ang kumpletong pag-aalis ng mga salungatan ay imposible sa daan-daang transitive dependency. Dependency Hell ay lumipat mula sa kategoryang "error sa build" patungo sa kategoryang "pamamahala ng panganib".

Mga uri ng salungatan ng dependency sa mga proyekto

Diamond dependency — klasiko. Ang aklatan A ay nakadepende sa D:1.0, ang aklatan B ay nakadepende sa D:2.0. Kung ang A at B ay ginamit nang magkasama, ang tagapamahala ng pakete ay dapat magpasya kung aling bersyon ng D ang i-install. Sa karamihan ng mga kaso, pinipili ang maximum na bersyon (2.0), ngunit kung ang A ay hindi tugma sa D:2.0 — ang salungatan ay hindi malulutas.

Salungatan ng bersyon — malinaw na hindi pagkakatugma ng mga kinakailangan. A ay nangangailangan ng Logging >=2.0, B ay nangangailangan ng Logging <2.0. Hindi matugunan ng tagapamahala ang parehong kondisyon. Salungatan ng peer dependency — plugin A ay nangangailangan ng React 17, ngunit ang proyekto ay gumagamit ng React 18 na may mga breaking changes. nagpapakita ang npm ng babala, ngunit nagpapatuloy ang pag-install — nagiging hindi mahuhulaan ang pag-uugali.

Impiyerno ng transitive dependency — kapag ang dependency ay hindi direkta, kundi hindi direkta. Hindi alam ng developer na ang aklatan A ay nakadepende sa B, at B ay nakadepende sa C. Gradle Dependency Tree — tool para sa pag-visualize ng buong chain ng dependency, na nagpapakita kung saan nagmula ang nagkakasalungatang aklatan.

Circular dependency — A ay nakadepende sa B, at B ay nakadepende sa A. Hinaharangan ng mga modernong tagapamahala (Gradle, npm) ang mga circular dependency sa yugto ng build. Solusyon — paghihiwalay ng karaniwang module C kung saan nakadepende ang A at B, pagsira sa cycle.

Paano lumitaw ang impiyerno ng dependency

Paglaki ng bilang ng mga aklatan — pangunahing paunang kondisyon. Ang bawat module ay nagdaragdag ng direkta at transitive dependency. Sa isang Android project na may Jetpack Compose, Firebase, Retrofit at Coil, ang bilang ng transitive dependency ay madaling lumampas sa 500. Ang bawat bagong aklatan ay potensyal na salungatan.

Hindi naka-sync na mga update — nag-a-update ang mga team ng mga aklatan sa iba't ibang oras. Ina-update ng backend team ang Jackson sa 2.15, gumagamit ang analytics team ng 2.12. Sa pagsasama ng mga module, lumitaw ang salungatan. Solusyon — sentralisadong bersyon (Bill of Materials) sa Gradle BOM file o catalog ng bersyon.

Iba't ibang bersyon ng parehong aklatan — klasikong sitwasyon: module A ay gumagamit ng OkHttp 3.12, module B — OkHttp 4.0. Kung ang update sa 4.0 ay sumira sa module A, ang proyekto ay maiipit sa dalawang bersyon, na maaaring humantong sa mga salungatan sa classpath sa Java o dobleng simbolo sa iOS.

Diagnosis ng problema sa proyekto

Gradle Dependency Tree — ang utos na `gradle dependencies` ay nagpapakita ng kumpletong puno ng dependency na may indikasyon ng mga salungatan. Ipinapakita ng Resolved version kung aling bersyon ang pinili ng Gradle, at ang mga bersyong nagkakasalungatan ay minarkahan ng mga arrow. Halimbawa: `com.squareup.okhttp3:okhttp -> 4.9.3 (*)` — nalutas ang bersyon, (*) — pagdoble.

npm ls — katulad na utos para sa Node.js. Ang flag na `--all` ay nagpapakita ng kumpletong puno. Ang mga salungatan ng peer dependency ay ipinapakita na may mga babala. SwiftPM Graph — `swift package show-dependencies` ay nagpapakita ng graph ng dependency para sa mga iOS project, kabilang ang mga branch at revision.

Dependency Analysis Plugin — Gradle plugin mula sa Autonomy na nakakahanap ng mga hindi nagamit na dependency at salungatan. Ben Manes Versions Plugin — sinusuri kung aling mga dependency ang luma at nagpapakita ng mga available na update. Ang parehong tool ay nag-automate ng routine compatibility check.

Halimbawa: pagsusuri ng salungatan sa Gradle

// Salungatan: module A ay nangangailangan ng okhttp 3.x, module B ay nangangailangan ng okhttp 4.x
dependencies {
    implementation("com.example:module-a:1.0")  // → okhttp 3.12
    implementation("com.example:module-b:2.0")  // → okhttp 4.0
}

// Solusyon: pilitin ang isang tiyak na bersyon
configurations.all {
    resolutionStrategy {
        force "com.squareup.okhttp3:okhttp:4.9.3"
    }
}

Mga tool sa paglutas ng salungatan

Version Catalog (Gradle 7+) — sentralisadong deklarasyon ng mga bersyon sa TOML file. Lahat ng module ay gumagamit ng parehong bersyon ng mga aklatan. Halimbawa: ang file na `libs.versions.toml` ay naglalaman ng `okhttp = "4.9.3"`, at lahat ng module ay tumutukoy sa catalog na ito. Ang salungatan ng bersyon sa pagitan ng mga module ay inaalis.

Bill of Materials (Spring BOM) — konsepto ng Maven kung saan tinutukoy ang mga tugmang bersyon ng mga aklatan. Ang Android team ng Google ay gumagamit ng Compose BOM para sa mga aklatan ng Jetpack. Sa pamamagitan ng pagkonekta ng BOM, makakakuha ka ng garantiya na ang lahat ng bersyon ng Compose ay tugma sa isa't isa.

Renovate at Dependabot — mga awtomatikong tagalikha ng PR para sa pag-update ng mga dependency. Pinagpangkat-pangkat ng Renovate ang mga tugmang update, sinusuri ang mga breaking changes sa pamamagitan ng mga imahe ng Docker. Dependabot — built-in na solusyon ng GitHub na nag-a-update ng mga dependency at sumusuri ng compatibility sa pamamagitan ng CI.

Mga estratehiya sa pagpigil sa impiyerno ng dependency

Semantic Versioning — gumamit ng caret `^1.2.3` para sa patch/minor update at tilde `~1.2.3` para lamang sa patch. Ngunit kahit ang semver ay hindi ginagarantiyahan ang compatibility — ang mga tunay na paglabag sa semver ay nangyayari sa 15% ng mga kaso (ayon sa pag-aaral ng University of Luxembourg, 2024). Ang mga lock file ay nag-aayos ng eksaktong bersyon na pumasa sa mga pagsubok.

Pag-minimize ng mga dependency — bawat aklatan ay dapat bigyang-katwiran. Kung maaari mong ipatupad ang functionality sa 20 linya ng iyong sariling code — huwag magdagdag ng aklatan. Halimbawa: sa halip na aklatan para sa pag-format ng petsa (4 transitive dependency) gamitin ang mga built-in na tool ng platform. Ang panuntunang "budget ng dependency" — hindi hihigit sa 50 direktang dependency bawat proyekto.

Regular na mga update — i-update ang mga dependency sa maliliit na hakbang, hindi isang beses sa isang taon. Gumagawa ang Dependabot ng PR para sa bawat update. Dapat patakbuhin ng CI ang kumpletong hanay ng mga pagsubok. DevContainer — pinag-isang kapaligiran ng pag-develop kung saan ang mga bersyon ng dependency ay tumutugma sa produksyon, inaalis ang mga salungatan sa pagitan ng mga kapaligiran.