Модуларност у мобилном развоју — суштина, принципи и организација

Шта је модуларност у мобилном развоју

Модуларност је начин организовања кода при којем се апликација састоји од слабо повезаних модула, од којих сваки пружа строго дефинисану функционалност кроз јавни интерфејс. За разлику од монолитне архитектуре, где су све класе у једном пројекту, модуларни приступ дели код на физички независне јединице компајлирања.

Основни циљ модуларности је управљање сложеношћу. Програмер се може фокусирати на један модул без држања целе кодовне базе у глави. Сваки модул има своју зону одговорности и може се развијати, тестирати и применљивати независно од осталих. Ово је посебно вредно у пројектима са 10+ програмера, где паралелни рад на монолиту доводи до честих конфликата спајања.

Важно је разликовати модуларност од слојевите архитектуре. Слојеви (Presentation, Domain, Data) деле код по техничком критеријуму, а модули — по функционалном. Модул „Кориснички профил“ може садржати сопствене слојеве унутар себе. У пракси се модуларни приступ и слојевита архитектура комбинују: сваки модул има своју трослојну структуру.

Врсте модула и њихова намена

Feature модули — најпопуларнија врста модула. Сваки екран или група повезаних екрана се издваја у посебан модул: Onboarding, Profile, Settings, Feed. Feature модул садржи све потребно за рад функције: UI, пословну логику, data слој. Границе модула су заштићене — друге функције не могу приступити његовим унутрашњим класама.

Core модули садрже заједничку инфраструктуру: рад са мрежом, базом података, аналитиком, дизајн системом. Они не зависе од feature модула, али feature модули зависе од њих. Таква подела гарантује да промена аналитичког SDK-а неће утицати на мрежни слој и обрнуто. Core модули се поново користе између функција без дуплирања кода.

Shared модули за заједничку логику

Shared модули садрже код који користе више функција: моделе података, алате, константе, прилагођене приказе. Главни проблем shared модула је ризик од претварања у депонију („misc module“), где се временом накупља разноврстан код. Правило: shared модул треба да има јасну тему, на пример „shared-ui“ или „shared-models“.

У Android-у се shared модули често издвајају у библиотеке са префиксом lib: lib-network, lib-database, lib-ui-components. У iOS-у исте функције обављају интерни Swift Packages унутар Workspace-а. У пракси тимови ограничавају број shared модула на 3–5 како не би створили прекомерну мрежу зависности која компликује компајлирање.

Тест модули и изолација тестирања

Одвојени тест модули омогућавају покретање тестова само за измењени модул, без покретања целе тест базе. Ово скраћује време CI/CD пајплајна са сати на минуте. Модули обезбеђују раздвајање на нивоу компајлирања: модул мрежног слоја не може случајно да увезе UI библиотеке у тестовима.

Сваки модул треба да има јасно дефинисан јавни API. У Android-у се то постиже кроз модификаторе приступа и api vs implementation у Gradle-у. У iOS-у — кроз public/internal модификаторе приступа и управљане зависности преко Package.swift-а. Смањење видљивости на минимум неопходан је кључна пракса модуларног дизајна.

Модуларност у Android-у: Gradle модули

Gradle подржава модуларну архитектуру изворно: сваки модул је посебна јединица компајлирања са својим build.gradle фајлом. Android пројекти користе комбинацију application модула (app) и неколико library модула. Библиотечки модули не могу се покренути као апликација, али се могу објавити као AAR у репозиторијуму.

Кључна функција Gradle-а је паралелно компајлирање независних модула. Ако модули A, B и C не зависе један од другог, Gradle их компајлира истовремено, користећи сва језгра процесора. У пројектима са 20+ модула ово скраћује потпуно компајлирање са 15 на 3–5 минута. Инкрементално компајлирање измењеног модула траје секунде.

Gradle пружа две врсте зависности између модула: api (транзитивне) и implementation (нетранзитивне). Разлика је критична за модуларност: implementation скрива транзитивне зависности од потрошача модула. Ако модул :profile користи :networking кроз implementation, потрошачи :profile не знају за :networking и не могу му приступити.

// settings.gradle — декларација модула
include ':app'
include ':feature:profile'
include ':feature:settings'
include ':core:network'
include ':core:database'

// build.gradle feature/profile — зависности модула
dependencies {
    implementation project(':core:network')
    implementation project(':core:database')
    implementation 'androidx.lifecycle:lifecycle-viewmodel-ktx:2.8.0'
}

Код приказује структуру модуларног Android пројекта. Settings.gradle набраја све модуле, а build.gradle сваког feature модула показује само оне core модуле који су му потребни. Систем компајлирања аутоматски решава транзитивне зависности и компајлира модуле у исправном редоследу.

Модуларност у iOS-у: Swift Package Manager и CocoaPods

Swift Package Manager (SPM) — стандардни алат за модуларност у iOS-у од 2019. године. SPM омогућава разбијање апликације на Swift Package-ове, од којих сваки може бити библиотека или извршни фајл. Package дефинише модуле (targets) и њихове зависности кроз Package.swift. SPM је интегрисан у Xcode и не захтева додатне алате.

CocoaPods остаје главни менаџер зависности за библиотеке трећих страна. Podfile и Podspec дефинишу модуларну структуру, а CocoaPods генерише workspace са одвојеним под пројектима. За сопствену модуларност пројекта, тимови све чешће бирају SPM, јер је уграђен у Xcode и не захтева инсталацију.

У iOS модуларности важну улогу игра контрола приступа: public, package, internal, fileprivate и private. Модул објављује само оне типове који треба да буду доступни другим модулима. Унутрашњи детаљи имплементације су скривени иза internal и private модификатора. Ово спречава настанак скривених зависности између модула.

// Package.swift — модуларна структура iOS пројекта
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 декларише два библиотечка производа: ProfileFeature и NetworkCore. ProfileFeature зависи од NetworkCore-а, али не зна за постојање Alamofire-а — он је скривен унутар NetworkCore-а. Таква изолација је директна примена раздвајања на нивоу модула: промене у HTTP клијенту не захтевају поновно компајлирање ProfileFeature-а.

Предности и изазови модуларне архитектуре

Главна предност модуларности је брзина развоја. Тимови раде паралелно на различитим модулима без конфликата у коду. CI/CD пајплајн компајлира само измењене модуле и покреће само њихове тестове. Време повратне информације се смањује, а учесталост издања расте. Spotify, Uber и Airbnb су објавили случајеве миграције на модуларну архитектуру са побољшањем метрика 2–3 пута.

Друга предност — изолација грешака. Грешка у модулу Profile не утиче на модул Payments, ако између њих нема директних зависности. Ово је посебно важно у апликацијама са високоризичним функцијама (плаћања, медицински подаци), где грешка у неповезаном екрану не треба да блокира издање критичне функционалности.

Главни изазов — управљање зависностима. При неправилном пројектовању настаје граф модула у ком промена једног модула каскадно прекомпајлира десетине других. Решење — праћење правила ацикличности: граф зависности модула мора бити усмерени ациклични граф (DAG). Алати попут Gradle Module Graph Assert помажу у откривању циклуса у фази компајлирања.

Други изазов — пораст времена почетног подешавања. Стварање модуларне архитектуре захтева више времена у фази иницијализације пројекта. Мали пројекти са 1–3 програмера можда неће имати користи од модуларности, трошећи време на одржавање граница модула без стварне потребе за паралелизацијом. Решење — почети са монолитом и издвајати модуле како тим расте.

Feature-first vs layer-first приступи

Feature-first приступ групише модуле по функционалности: сваки екран или група екрана постаје посебан модул. Layer-first приступ дели код по техничком критеријуму: посебни модули за UI, пословну логику и податке. У пракси већина тимова бира feature-first са core модулима — ово даје бољу изолацију и јасну навигацију кроз пројекат.

Избор између приступа зависи од величине тима и предвидивости функционалности. Ако тачно знате који екрани ће бити у пројекту, feature-first омогућава сваком програмеру да буде одговоран за свој модул. Ако се функционалност често мења и преклапа између екрана, layer-first пружа већу флексибилност при поновном коришћењу кода између различитих функција.