0Pricing
Android Academy · Ders

Modülerleştirme Neden Kullanılır

Derleme hızı, sahiplik ve yeniden kullanım.

Modülerleştirme Neden Kullanılır, CoddyKit'te ücretsiz bir Android Academy dersidir. Bu, 4 dersinin 1. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, Android Academy öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. Android Academy kursu toplamda 4 dersten oluşur.

Monolit Sorunu

Bir Android uygulaması büyüdüğünde, tüm kodu genellikle tek bir app modülünde yaşar. Buna monolit denir. Başta kullanışlıdır; ancak zamanla sorun oluşturmaya başlar: her değişiklik aynı modüle dokunur, derlemeler yavaşlar ve ekip üyeleri sürekli birbirlerinin çalışmalarına engel olur.

Modülerleştirme, bu büyük modülü daha küçük ve odaklanmış birçok Gradle modülüne bölmek demektir. Bu derste ekiplerin bunu neden yaptığını ve sağladığı somut yararları öğreneceksiniz.

Modül Aslında Nedir

Gradle'da modül, kendine ait build.gradle.kts dosyası olan ve bağımsız olarak derlenebilen bir kod birimidir. Uygulamanızda zaten en az bir modül vardır: :app modülü. Her modülü settings.gradle.kts içinde tanımlarsınız.

Modül eklemek, onu dahil etmek kadar basittir. Her modül kendi derleme çıktısını üretir ve diğer modüllere bağımlı olabilir.

// settings.gradle.kts
include(":app")
include(":core:designsystem")
include(":core:data")
include(":feature:home")
include(":feature:profile")

1. Fayda: Daha Hızlı Derlemeler

En büyük pratik kazanç derleme hızıdır. Gradle modülleri paralel olarak derleyebilir ve daha da önemlisi, girdileri değişmeyen modülleri önbelleğe alıp atlayabilir.

Yalnızca :feature:profile üzerinde değişiklik yaparsanız Gradle, diğer tüm modüllerin önceden derlenmiş çıktılarını yeniden kullanır. Monolitik bir yapıda herhangi bir değişiklik, tüm uygulamanın yeniden derlenmesini zorunlu kılabilir.

  • Modüller arasında paralel yürütme
  • Aşamalı derlemeler: yalnızca değişenleri yeniden derleme
  • Daha yüksek uzak/derleme önbelleği isabet oranları
// gradle.properties
org.gradle.parallel=true
org.gradle.caching=true
org.gradle.configuration-cache=true

2. Fayda: Net Sınırlar

Modüller sınırları zorunlu kılar. Bir modüldeki kod, başka bir modülün yalnızca bilerek dışa açtığı şeyleri görebilir. Bu, her sınıfın diğer tüm sınıfların içine eriştiği karmaşık yapıların oluşmasını önler.

Görünürlüğü api ve implementation Gradle yapılandırmalarıyla denetlersiniz. implementation, bir bağımlılığı modüle özel tutar; modülü kullananlar bu bağımlılığı yanlışlıkla kullanamaz.

// feature/profile/build.gradle.kts
dependencies {
    // Exposed to whoever depends on :feature:profile
    api(project(":core:model"))

    // Private: hidden from consumers of this module
    implementation(project(":core:network"))
}

3. Fayda: Yeniden Kullanım

Mantık odaklanmış bir modülde yaşadığında onu istediğiniz yerde yeniden kullanabilirsiniz. Temanızı, renklerinizi ve yeniden kullanılabilir bileştiricilerinizi barındıran bir :core:designsystem modülü her özellik tarafından paylaşılabilir.

Aynı fikir birden çok uygulamaya da ölçeklenir: bir şirket, kodu kopyalamak yerine :core:network modülünü birkaç ürün arasında paylaşabilir.

// Any feature can pull in shared building blocks
// feature/home/build.gradle.kts
dependencies {
    implementation(project(":core:designsystem"))
    implementation(project(":core:data"))
}

4. Fayda: Ekip Sahipliği

Modüller ekip sahipliğiyle düzgün biçimde eşleşir. Ödeme ekibi :feature:payments modülünün, profil ekibi ise :feature:profile modülünün sahibidir. Kodları ayrı klasörlerde ve derleme dosyalarında bulunduğundan, daha az birleştirme çakışmasıyla paralel çalışabilirler.

CODEOWNERS dosyası gibi araçlar, modül yoluna göre doğru ekipten inceleme isteğini otomatik olarak gönderebilir.

# .github/CODEOWNERS
/feature/payments/   @org/payments-team
/feature/profile/    @org/profile-team
/core/designsystem/  @org/platform-team

5. Fayda: Görünürlükle Kapsülleme

Bir modül içinde Kotlin'in internal değiştiricisi güçlü hale gelir. internal bir sınıf veya işlev yalnızca kendi modülü içinde görünürdür. Diğer modüller ona başvuramaz.

Bu sayede küçük bir ortak arayüzü dışa açıp uygulama ayrıntılarını gizleyebilirsiniz; tek ve dev bir modülde bunu zorunlu kılmak mümkün değildir.

// In :core:data
// Public API other modules may use
fun interface UserRepository {
    suspend fun loadUser(id: String): User
}

// Hidden from other modules
internal class DefaultUserRepository(
    private val api: UserApi
) : UserRepository {
    override suspend fun loadUser(id: String) = api.fetch(id).toUser()
}

Bedeli: Biraz Ek Yük

Modülerleştirme ücretsiz değildir. Her modül, bakımı yapılacak bir build.gradle.kts dosyası ekler ve her kod parçasının hangi modüle ait olduğunu düşünmeniz gerekir. Küçük bir uygulamayı aşırı modülerleştirmek, karşılığında fayda sağlamadan gereksiz iş oluşturur.

Genel kural şudur: Derleme süreleri canınızı sıkmaya başladığında, ekipler birbirine engel olduğunda veya açıkça yeniden kullanılabilir katmanlarınız bulunduğunda modülerleştirin. Hafta sonu yapılan bir hobi uygulamasının nadiren 30 modüle ihtiyacı olur.

Tipik Bir Modül Düzeni

Yaygın ve ölçeklenebilir bir yapı, modülleri app, feature ve core katmanlarına ayırır. :app modülü her şeyi birbirine bağlar; özellikler kullanıcıya sunulan ekranları barındırır; çekirdek modüller ortak altyapıyı içerir.

// Conceptual project tree
// app/                  <- single entry point, wires features
// feature/
//   home/
//   profile/
//   settings/
// core/
//   designsystem/       <- theme + reusable composables
//   data/               <- repositories
//   network/            <- Retrofit/Ktor
//   model/              <- shared data classes

Kural Eklentileri Yapıyı Düzenli Tutar

Çok sayıda modül olduğunda aynı Gradle kurulumunu her yere kopyalayıp yapıştırmak bir tuzaktır. Ekipler ortak yapılandırmayı kural eklentileri (bir build-logic modülünde) hâline getirir. Böylece her gerçek modül, onlarca satırı tekrarlamak yerine tek bir eklenti uygular.

Bu kalıbı Now in Android gibi büyük açık kaynaklı uygulamalarda göreceksiniz. Şimdilik yalnızca amacı bilmeniz yeterli: derleme dosyalarını küçük ve tutarlı tutmak.

// feature/home/build.gradle.kts
plugins {
    // One convention plugin sets up Android + Compose + Kotlin
    id("myapp.android.feature")
}

android { namespace = "com.myapp.feature.home" }

Bakış Açısı: Katmanlar Üzerinden Düşünün

En kullanışlı zihinsel model şudur: bağımlılıklar aşağı doğru akmalıdır. Özellikler çekirdeğe bağımlıdır; çekirdek özelliklere bağımlı değildir. :app modülü en üstte yer alır ve uygulamayı birleştirmek için ihtiyaç duyduğu her şeye bağımlıdır.

Bu yönü tutarlı korursanız modül grafiğiniz temiz kalır ve daha sonraki bir derste inceleyeceğiniz döngülerden kaçınırsınız.

// Allowed:  app -> feature -> core
// Forbidden: core -> feature (upward) or feature -> feature (sideways)
// app/build.gradle.kts
dependencies {
    implementation(project(":feature:home"))
    implementation(project(":feature:profile"))
}

Hızlı Kontrol

Büyüyen bir Android uygulamasını modülerleştirmenin ekiplerin elde ettiği en somut ve günlük faydası aşağıdakilerden hangisidir?

Özet: Neden Modülerleştirmeli

Ekiplerin bir monoliti neden modüllere ayırdığını öğrendiniz:

  • Paralel yürütme ve aşamalı önbelleğe alma sayesinde daha hızlı derlemeler
  • api/implementation ve internal kullanarak net sınırlar
  • Tasarım sistemi ve ağ gibi çekirdek katmanların yeniden kullanımı
  • Daha az birleştirme çakışmasıyla ekip sahipliği

Maliyeti (ek derleme dosyaları) ve altın kuralı da gördünüz: bağımlılıklar aşağı doğru akar, app -> feature -> core. Sırada özellik ve çekirdek modülleri arasındaki gerçek sınırları çizeceksiniz.

Sıkça Sorulan Sorular

“Modülerleştirme Neden Kullanılır” dersi ücretsiz mi?

Evet — “Modülerleştirme Neden Kullanılır” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve Android Academy kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. Android Academy kursu toplamda 4 dersten oluşur.

“Modülerleştirme Neden Kullanılır” dersinde ne öğreneceğim?

Derleme hızı, sahiplik ve yeniden kullanım. Android Academy ile uygulamalı kodu tarayıcıda doğrudan çalıştırarak pratik yaparsın ve 7/24 yapay zeka koçu dersi çalışırken sorularını yanıtlar.

Android Academy öğrenmeye başlamak için deneyim gerekli mi?

Önceden deneyim gerekmez. CoddyKit'te Android Academy, başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 1. dersidir.

“Modülerleştirme Neden Kullanılır” dersi ne kadar sürer?

Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.

Bu Android Academy dersinde kod yazıp çalıştırabilir miyim?

Evet. Her Android Academy dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.

Bu kursun tüm dersleri

  1. Modülerleştirme Neden Kullanılır
  2. Özellik ve Çekirdek Modüller
  3. Modül Bağımlılıklarını Yönetme
  4. Modüller Arası Gezinme
← Android Academy Sayfasına Dön