Mobil ishlab chiqishda modullilik — mohiyati, tamoyillari va tashkil qilish

Mobil ishlab chiqishda modullilik nima

Modullilik — bu kodni tashkil qilish usuli bo‘lib, ilova zaif bog‘langan modullardan iborat bo‘ladi, ularning har biri umumiy interfeys orqali qat‘iy belgilangan funksionallikni ta’minlaydi. Barcha sinflar bitta loyihada bo‘lgan monolit arxitekturadan farqli o‘laroq, modul yondashuvi kodni jismoniy jihatdan mustaqil qurilish birliklariga ajratadi.

Modullilikning asosiy maqsadi — murakkablikni boshqarish. Dasturchi butun kod bazasini miyasida saqlamasdan bitta modulga e’tibor qaratishi mumkin. Har bir modul o‘z mas’uliyat zonasiga ega va qolganlaridan mustaqil ravishda ishlab chiqilishi, sinovdan o‘tkazilishi va joylashtirilishi mumkin. Bu, ayniqsa, 10+ dasturchisi bo‘lgan loyihalarda qimmatlidir, chunki monolit ustida parallel ishlash tez-tez birlashtirish mojarolariga olib keladi.

Modullilikni qatlamli arxitekturadan farqlash muhimdir. Qatlamlar (Presentation, Domain, Data) kodni texnik mezon bo‘yicha, modullar esa funksional mezon bo‘yicha ajratadi. “Foydalanuvchi profili” moduli o‘z ichida o‘z qatlamlarini o‘z ichiga olishi mumkin. Amalda modul yondashuvi va qatlamli arxitektura birlashtiriladi: har bir modul o‘zining uch qatlamli tuzilishiga ega.

Modul turlari va ularning vazifasi

Feature-modullar — eng mashhur modul turi. Har bir ekran yoki bog‘liq ekranlar guruhi alohida modulga ajratiladi: Onboarding, Profile, Settings, Feed. Feature-modul funksiyaning ishlashi uchun zarur bo‘lgan hamma narsani o‘z ichiga oladi: UI, biznes mantiq, ma’lumotlar qatlami. Modulning chegaralari himoyalangan — boshqa funksiyalar uning ichki sinflariga kira olmaydi.

Core-modullar umumiy infratuzilmani o‘z ichiga oladi: tarmoq bilan ishlash, ma’lumotlar bazasi, analitika, dizayn tizimi. Ular feature-modullarga bog‘liq emas, lekin feature-modullar ularga bog‘liq. Bunday bo‘linish analitik SDKni o‘zgartirish tarmoq qatlamiga ta’sir qilmasligini kafolatlaydi va aksincha. Core-modullar kod takrorlanmasdan funksiyalar o‘rtasida qayta ishlatiladi.

Umumiy mantiq uchun Shared modullar

Shared-modullar bir nechta funksiyalar tomonidan ishlatiladigan kodni o‘z ichiga oladi: ma’lumotlar modellari, utilitalar, konstantalar, moslashtirilgan Viewlar. Shared-modullarning asosiy muammosi — vaqt o‘tishi bilan turli xil kod to‘planadigan axlatxonaga (“misc module”) aylanish xavfi. Qoida: shared-modul aniq mavzuga ega bo‘lishi kerak, masalan “shared-ui” yoki “shared-models”.

Androidda shared-modullar ko‘pincha lib prefiksi bilan kutubxonalarga ajratiladi: lib-network, lib-database, lib-ui-components. iOSda xuddi shu vazifalarni Workspace ichidagi ichki Swift Packages bajaradi. Amalda jamoalar qurilishni murakkablashtiradigan haddan tashqari bog‘liqlik tarmog‘ini yaratmaslik uchun shared-modullar sonini 3–5 bilan cheklaydi.

Test modullari va test izolyatsiyasi

Alohida test modullari butun test bazasini ishga tushirmasdan, faqat o‘zgartirilgan modul uchun testlarni ishga tushirish imkonini beradi. Bu CI/CD pipeline vaqtini soatlardan daqiqalarga qisqartiradi. Modullar qurilish darajasida ajratishni ta’minlaydi: tarmoq qatlamining moduli testlarda tasodifan UI kutubxonalarini import qila olmaydi.

Har bir modul aniq belgilangan umumiy APIga ega bo‘lishi kerak. Androidda bunga kirish modifierlari va Gradledagi api vs implementation orqali erishiladi. iOSda — public/internal kirish modifierlari va Package.swift orqali boshqariladigan bog‘liqliklar. Ko‘rinishni minimal zarur darajaga tushirish modul dizaynining asosiy amaliyotidir.

Androidda modullilik: Gradle modullari

Gradle modul arxitekturasini mahalliy darajada qo‘llab-quvvatlaydi: har bir modul o‘z build.gradle fayliga ega alohida qurilish birligidir. Android loyihalari application moduli (app) va bir nechta library modullarining kombinatsiyasidan foydalanadi. Kutubxona modullari ilova sifatida ishga tushirilmaydi, lekin AAR sifatida repozitoriyada nashr etilishi mumkin.

Gradlening asosiy xususiyati — mustaqil modullarning parallel qurilishi. Agar A, B va C modullari bir-biriga bog‘liq bo‘lmasa, Gradle ularni bir vaqtning o‘zida, protsessorning barcha yadrolaridan foydalanib kompilyatsiya qiladi. 20+ modulli loyihalarda bu to‘liq qurilishni 15 daqiqadan 3–5 daqiqagacha qisqartiradi. O‘zgartirilgan modulning inkremental qurilishi soniyalar davom etadi.

Gradle modullar o‘rtasida ikki turdagi bog‘liqlikni ta’minlaydi: api (tranzitiv) va implementation (tranzitiv bo‘lmagan). Farq modullilik uchun muhim ahamiyatga ega: implementation modul iste’molchilaridan tranzitiv bog‘liqliklarni yashiradi. Agar :profile moduli :networkingni implementation orqali ishlatsa, :profile iste’molchilari :networking haqida bilmaydi va unga murojaat qila olmaydi.

// settings.gradle — modullar deklaratsiyasi
include ':app'
include ':feature:profile'
include ':feature:settings'
include ':core:network'
include ':core:database'

// build.gradle feature/profile — modul bog‘liqliklari
dependencies {
    implementation project(':core:network')
    implementation project(':core:database')
    implementation 'androidx.lifecycle:lifecycle-viewmodel-ktx:2.8.0'
}

Kod modul Android loyihasining tuzilishini ko‘rsatadi. Settings.gradle barcha modullarni sanab o‘tadi, har bir feature-modulning build.gradle esa faqat o‘ziga kerakli core-modullarni ko‘rsatadi. Qurilish tizimi avtomatik ravishda tranzitiv bog‘liqliklarni hal qiladi va modullarni to‘g‘ri tartibda yig‘adi.

iOSda modullilik: Swift Package Manager va CocoaPods

Swift Package Manager (SPM) — 2019-yildan beri iOSda modullilik uchun standart vosita. SPM ilovani har biri kutubxona yoki bajariladigan fayl bo‘lishi mumkin bo‘lgan Swift Packagelarga bo‘lish imkonini beradi. Package modullarni (targets) va ularning bog‘liqliklarini Package.swift orqali belgilaydi. SPM Xcode bilan integratsiyalangan va qo‘shimcha vositalarni talab qilmaydi.

CocoaPods uchinchi tomon kutubxonalari uchun asosiy bog‘liqlik menejeri bo‘lib qolmoqda. Podfile va Podspec modul tuzilishini belgilaydi, CocoaPods esa alohida pod loyihalari bilan workspace yaratadi. Loyihaning o‘z modulliligi uchun jamoalar tobora ko‘proq SPMni tanlaydilar, chunki u Xcodega o‘rnatilgan va o‘rnatishni talab qilmaydi.

iOS modulliligida kirish nazorati muhim rol o‘ynaydi: public, package, internal, fileprivate va private. Modul faqat boshqa modullar uchun mavjud bo‘lishi kerak bo‘lgan turlarni nashr etadi. Ichki amalga oshirish tafsilotlari internal va private modifierlari orqasida yashirinadi. Bu modullar o‘rtasida yashirin bog‘liqliklarning paydo bo‘lishining oldini oladi.

// Package.swift — iOS loyihasining modul tuzilishi
let package = Package(
    name: "MyApp",
    platforms: [.iOS(SupportedPlatform.iOSVersion.v17)],
    products: [
        .library(name: "ProfileFeature", targets: ["ProfileFeature"]),
        .library(name: "NetworkCore", targets: ["NetworkCore"]),
    ],
    dependencies: [
        .package(url: "https://github.com/Alamofire/Alamofire.git", from: "5.9.0")
    ],
    targets: [
        .target(name: "ProfileFeature", dependencies: ["NetworkCore"]),
        .target(name: "NetworkCore", dependencies: ["Alamofire"]),
    ]
)

Package.swift ikkita kutubxona mahsulotini e‘lon qiladi: ProfileFeature va NetworkCore. ProfileFeature NetworkCorega bog‘liq, lekin Alamofire mavjudligidan xabardor emas — u NetworkCore ichida yashiringan. Bunday izolyatsiya modul darajasida ajratishning bevosita qo‘llanilishidir: HTTP mijozidagi o‘zgarishlar ProfileFeaturening qayta kompilyatsiyasini talab qilmaydi.

Modul arxitekturasining afzalliklari va qiyinchiliklari

Modullilikning asosiy afzalligi — ishlab chiqish tezligi. Jamoalar turli modullar ustida koddagi mojarolarsiz parallel ishlaydi. CI/CD pipeline faqat o‘zgartirilgan modullarni yig‘adi va faqat ularning testlarini ishga tushiradi. Fikr-mulohaza vaqti qisqaradi, relizlar chastotasi oshadi. Spotify, Uber va Airbnb modul arxitekturasiga migratsiya holatlarini 2–3 marta ko‘rsatkichlar yaxshilanishi bilan nashr etgan.

Ikkinchi afzallik — xatolarni izolyatsiya qilish. Profile modulidagi xato Payments moduliga ta’sir qilmaydi, agar ular o‘rtasida to‘g‘ridan-to‘g‘ri bog‘liqliklar bo‘lmasa. Bu, ayniqsa, yuqori xavfli funksiyalari (to‘lovlar, tibbiy ma’lumotlar) bo‘lgan ilovalarda muhimdir, chunki bog‘liq bo‘lmagan ekrandagi xato muhim funksionallik relizini bloklamasligi kerak.

Asosiy qiyinchilik — bog‘liqliklarni boshqarish. Noto‘g‘ri loyihalashda bir modulning o‘zgarishi o‘nlab boshqa modullarni kaskadli ravishda qayta qurishga olib keladigan modul grafi paydo bo‘ladi. Yechim — asikliklik qoidasiga rioya qilish: modul bog‘liqliklari grafi yo‘naltirilgan asiklik graf (DAG) bo‘lishi kerak. Gradle Module Graph Assert kabi vositalar qurilish bosqichida sikllarni aniqlashga yordam beradi.

Ikkinchi qiyinchilik — dastlabki sozlash vaqtining oshishi. Modul arxitekturasini yaratish loyihaning boshlang‘ich bosqichida ko‘proq vaqt talab qiladi. 1–3 dasturchisi bo‘lgan kichik loyihalar modullilikdan foyda ko‘rmasligi mumkin, parallellashtirishga haqiqiy ehtiyoj bo‘lmasa, modul chegaralarini saqlashga vaqt sarflaydi. Yechim — monolitdan boshlash va jamoa o‘sgan sari modullarni ajratish.

Feature-first va layer-first yondashuvlari

Feature-first yondashuvi modullarni funksionallik bo‘yicha guruhlaydi: har bir ekran yoki ekranlar guruhi alohida modulga aylanadi. Layer-first yondashuvi kodni texnik mezon bo‘yicha ajratadi: UI, biznes mantiq va ma’lumotlar uchun alohida modullar. Amalda ko‘pchilik jamoalar core-modullari bilan feature-firstni tanlaydilar — bu yaxshiroq izolyatsiya va loyiha bo‘ylab aniq navigatsiyani beradi.

Yondashuvlar o‘rtasidagi tanlov jamoaning kattaligi va funksionallikning bashorat qilish mumkinligiga bog‘liq. Loyihada qanday ekranlar bo‘lishini aniq bilsangiz, feature-first har bir dasturchiga o‘z moduli uchun javobgar bo‘lish imkonini beradi. Funksionallik tez-tez o‘zgarib, ekranlar o‘rtasida kesishsa, layer-first turli funksiyalar o‘rtasida kodni qayta ishlatishda ko‘proq moslashuvchanlik beradi.