0Pricing
Android Academy · Pelajaran

Mengapa Membuat Modul

Kecepatan build, kepemilikan, dan penggunaan ulang.

Mengapa Membuat Modul adalah pelajaran Android Academy gratis di CoddyKit. Ini adalah pelajaran 1 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar Android Academy, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus Android Academy mencakup 4 pelajaran total.

Masalah Monolit

Saat aplikasi Android berkembang, semua kodenya sering berada dalam satu modul app. Inilah yang disebut monolit. Awalnya hal ini praktis, tetapi lama-kelamaan menjadi merepotkan: setiap perubahan menyentuh modul yang sama, proses build menjadi lambat, dan anggota tim terus saling mengganggu pekerjaan.

Modularisasi berarti memecah satu modul besar tersebut menjadi banyak modul Gradle yang lebih kecil dan berfokus. Dalam pelajaran ini, Anda akan mempelajari alasan tim melakukan hal ini dan manfaat nyata yang diperoleh.

Apa Sebenarnya Modul Itu

Dalam Gradle, modul adalah unit kode yang dapat dibangun secara mandiri dan memiliki file build.gradle.kts sendiri. Aplikasi Anda setidaknya sudah memiliki satu modul: modul :app. Anda mendeklarasikan setiap modul di settings.gradle.kts.

Menambahkan modul cukup dilakukan dengan menyertakannya. Setiap modul menghasilkan keluaran build sendiri dan dapat bergantung pada modul lain.

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

Manfaat 1: Build Lebih Cepat

Manfaat praktis terbesar adalah kecepatan build. Gradle dapat membangun modul secara paralel dan, yang terpenting, menyimpan di cache serta melewati modul yang inputnya tidak berubah.

Jika Anda hanya mengedit :feature:profile, Gradle menggunakan kembali keluaran yang sudah dibangun dari semua modul lainnya. Dalam monolit, perubahan apa pun dapat memaksa kompilasi ulang seluruh aplikasi.

  • Eksekusi paralel di seluruh modul
  • Build inkremental: hanya membangun ulang bagian yang berubah
  • Tingkat keberhasilan penggunaan cache jarak jauh/build yang lebih baik
// gradle.properties
org.gradle.parallel=true
org.gradle.caching=true
org.gradle.configuration-cache=true

Manfaat 2: Batas yang Jelas

Modul menerapkan batasan. Kode dalam satu modul hanya dapat melihat hal-hal yang sengaja dibuka oleh modul lain. Ini mencegah kode menjadi kusut seperti spageti, ketika setiap kelas mengakses kelas lainnya.

Anda mengatur visibilitas dengan konfigurasi Gradle api dan implementation. implementation menjaga dependensi tetap privat bagi modul; pengguna modul tidak dapat menggunakannya secara tidak sengaja.

// 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"))
}

Manfaat 3: Penggunaan Ulang

Setelah logika ditempatkan dalam modul yang berfokus, Anda dapat menggunakannya kembali di mana saja. Modul :core:designsystem yang menyimpan tema, warna, dan composable yang dapat digunakan kembali dapat dibagikan oleh setiap fitur.

Gagasan yang sama juga berlaku untuk beberapa aplikasi: sebuah perusahaan dapat membagikan modul :core:network ke beberapa produk, bukan menyalin kode.

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

Manfaat 4: Kepemilikan Tim

Modul sangat sesuai dengan kepemilikan tim. Tim pembayaran memiliki :feature:payments; tim profil memiliki :feature:profile. Mereka dapat bekerja secara paralel dengan lebih sedikit konflik penggabungan karena kode mereka berada dalam folder dan file build yang terpisah.

Alat seperti file CODEOWNERS dapat secara otomatis meminta peninjauan dari tim yang tepat berdasarkan jalur modul.

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

Manfaat 5: Enkapsulasi melalui Visibilitas

Di dalam sebuah modul, pengubah internal milik Kotlin menjadi sangat berguna. Kelas atau fungsi internal terlihat hanya di dalam modulnya sendiri. Modul lain benar-benar tidak dapat merujuknya.

Dengan demikian, Anda dapat membuka permukaan publik yang kecil dan menyembunyikan detail implementasi, sesuatu yang tidak dapat dipaksakan dalam satu modul raksasa.

// 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()
}

Biayanya: Ada Sedikit Beban Tambahan

Modularisasi tidak gratis. Setiap modul menambahkan build.gradle.kts yang harus dipelihara, dan Anda harus menentukan modul yang memiliki setiap bagian kode. Modularisasi berlebihan pada aplikasi kecil hanya menambah pekerjaan tanpa manfaat.

Aturan praktisnya: lakukan modularisasi saat waktu build mulai mengganggu, saat tim saling berbenturan, atau saat Anda memiliki lapisan yang jelas dan dapat digunakan kembali. Aplikasi hobi yang dikerjakan pada akhir pekan jarang memerlukan 30 modul.

Susunan Modul yang Umum

Struktur umum yang dapat diskalakan membagi modul menjadi lapisan app, feature, dan core. Modul :app menghubungkan semuanya; fitur berisi layar yang berhadapan langsung dengan pengguna; modul core berisi infrastruktur bersama.

// 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

Plugin Konvensi Menjaga Kerapian

Dengan banyak modul, menyalin dan menempelkan penyiapan Gradle yang sama di mana-mana adalah jebakan. Tim mengekstrak konfigurasi bersama ke dalam plugin konvensi (di modul build-logic). Setiap modul sebenarnya kemudian menerapkan satu plugin, bukan mengulangi puluhan baris.

Anda akan melihat pola ini dalam aplikasi sumber terbuka besar seperti Now in Android. Untuk saat ini, cukup pahami tujuannya: menjaga file build tetap kecil dan konsisten.

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

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

Pola Pikir: Berpikir dalam Lapisan

Model mental yang paling berguna adalah: dependensi harus mengalir ke bawah. Fitur bergantung pada core; core tidak bergantung pada fitur. Modul :app berada paling atas dan bergantung pada semua hal yang diperlukan untuk merakit aplikasi.

Jika arah ini tetap konsisten, grafik modul Anda tetap bersih dan Anda terhindar dari siklus, yang akan dipelajari dalam pelajaran berikutnya.

// 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"))
}

Pemeriksaan Singkat

Manakah dari berikut ini yang merupakan manfaat paling nyata dalam keseharian yang diperoleh tim dengan memodularisasi aplikasi Android yang terus berkembang?

Ringkasan: Alasan Melakukan Modularisasi

Anda telah mempelajari alasan tim memecah monolit menjadi beberapa modul:

  • Build lebih cepat melalui eksekusi paralel dan caching inkremental
  • Batas yang jelas menggunakan api/implementation dan internal
  • Penggunaan ulang lapisan core seperti sistem desain dan jaringan
  • Kepemilikan tim dengan lebih sedikit konflik penggabungan

Anda juga telah melihat biayanya (file build tambahan) dan aturan emasnya: dependensi mengalir ke bawah, app -> feature -> core. Berikutnya, Anda akan menggambar batas nyata antara modul feature dan core.

Pertanyaan yang Sering Diajukan

Apakah pelajaran “Mengapa Membuat Modul” gratis?

Ya — teks lengkap “Mengapa Membuat Modul” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus Android Academy, upgrade ke CoddyKit PRO. Kursus Android Academy mencakup 4 pelajaran total.

Apa yang akan aku pelajari di “Mengapa Membuat Modul”?

Kecepatan build, kepemilikan, dan penggunaan ulang. Kamu berlatih Android Academy dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.

Apakah aku perlu pengalaman untuk memulai Android Academy?

Tidak diperlukan pengalaman sebelumnya. Android Academy di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 1 dari 4.

Berapa lama pelajaran “Mengapa Membuat Modul” memakan waktu?

Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.

Bisakah aku menulis dan menjalankan kode dalam pelajaran Android Academy ini?

Ya. Setiap pelajaran Android Academy menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.

Semua pelajaran dalam kursus ini

  1. Mengapa Membuat Modul
  2. Modul Fitur dan Inti
  3. Mengelola Dependensi Modul
  4. Navigasi Antar-Modul
← Kembali ke Android Academy