Por qué modularizar
Velocidad de compilación, responsabilidad y reutilización
Por qué modularizar es una lección gratuita de Android Academy en CoddyKit. Esta es la lección 1 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de Android Academy, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de Android Academy incluye 4 lecciones en total.
El problema del monolito
Cuando una aplicación Android crece, todo su código suele vivir en un único módulo app. Esto es un monolito. Al principio resulta práctico, pero con el tiempo se vuelve problemático: cada cambio afecta al mismo módulo, las compilaciones se ralentizan y los miembros del equipo interfieren constantemente en el trabajo de los demás.
La modularización consiste en dividir ese módulo grande en muchos módulos de Gradle más pequeños y especializados. En esta lección aprenderá por qué los equipos lo hacen y qué beneficios concretos aporta.
Qué es realmente un módulo
En Gradle, un módulo es una unidad de código que se puede compilar de forma independiente y que tiene su propio archivo build.gradle.kts. Su aplicación ya tiene al menos uno: el módulo :app. Debe declarar todos los módulos en settings.gradle.kts.
Añadir un módulo es tan sencillo como incluirlo. Cada módulo produce su propia salida de compilación y puede depender de otros módulos.
// settings.gradle.kts
include(":app")
include(":core:designsystem")
include(":core:data")
include(":feature:home")
include(":feature:profile")Ventaja 1: compilaciones más rápidas
La ventaja práctica más importante es la velocidad de compilación. Gradle puede compilar los módulos en paralelo y, sobre todo, almacenar en caché y omitir los módulos cuyas entradas no hayan cambiado.
Si edita únicamente :feature:profile, Gradle reutiliza las salidas ya compiladas de todos los demás módulos. En un monolito, cualquier cambio puede obligar a recompilar toda la aplicación.
- Ejecución en paralelo entre módulos
- Compilaciones incrementales: solo se recompila lo que cambió
- Mejores tasas de aciertos de la caché local o remota
// gradle.properties
org.gradle.parallel=true
org.gradle.caching=true
org.gradle.configuration-cache=trueVentaja 2: límites claros
Los módulos imponen límites. El código de un módulo solo puede acceder a lo que otro módulo expone deliberadamente. Esto evita el código espagueti en el que cada clase accede a todas las demás.
Puede controlar la visibilidad con las configuraciones de Gradle api y implementation. implementation mantiene una dependencia privada dentro del módulo; los consumidores no pueden usarla accidentalmente.
// 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"))
}Ventaja 3: reutilización
Cuando la lógica reside en un módulo especializado, puede reutilizarla en cualquier lugar. Un módulo :core:designsystem que contenga el tema, los colores y los composables reutilizables puede compartirse entre todas las funcionalidades.
La misma idea se aplica a varias aplicaciones: una empresa puede compartir un módulo :core:network entre varios productos en lugar de copiar el código.
// Any feature can pull in shared building blocks
// feature/home/build.gradle.kts
dependencies {
implementation(project(":core:designsystem"))
implementation(project(":core:data"))
}Ventaja 4: responsabilidad del equipo
Los módulos se corresponden claramente con la responsabilidad de cada equipo. El equipo de pagos es responsable de :feature:payments y el equipo de perfil, de :feature:profile. Pueden trabajar en paralelo con menos conflictos de combinación porque su código se encuentra en carpetas y archivos de compilación separados.
Herramientas como un archivo CODEOWNERS pueden solicitar automáticamente revisiones al equipo adecuado según la ruta del módulo.
# .github/CODEOWNERS
/feature/payments/ @org/payments-team
/feature/profile/ @org/profile-team
/core/designsystem/ @org/platform-teamVentaja 5: encapsulación mediante visibilidad
Dentro de un módulo, el modificador internal de Kotlin se vuelve muy útil. Una clase o función internal es visible solo dentro de su propio módulo. Los demás módulos no pueden referenciarla.
Esto permite exponer una superficie pública reducida y ocultar los detalles de implementación, algo que no se puede imponer en un único módulo enorme.
// 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()
}El coste: cierta sobrecarga
La modularización no es gratuita. Cada módulo añade un archivo build.gradle.kts que mantener, y debe pensar qué módulo es responsable de cada parte del código. Modularizar en exceso una aplicación pequeña genera trabajo innecesario sin aportar beneficios.
Como regla general: modularice cuando los tiempos de compilación sean un problema, cuando los equipos interfieran entre sí o cuando tenga capas reutilizables bien definidas. Una aplicación personal de fin de semana rara vez necesita 30 módulos.
Una estructura de módulos habitual
Una estructura común y escalable divide los módulos en las capas app, feature y core. El módulo :app conecta todos los elementos; las funcionalidades contienen las pantallas que usa el usuario; los módulos core contienen la infraestructura compartida.
// 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 classesLos convention plugins mantienen el orden
Cuando hay muchos módulos, copiar y pegar la misma configuración de Gradle en todas partes es una trampa. Los equipos extraen la configuración compartida en convention plugins (en un módulo build-logic). Después, cada módulo real aplica un único plugin en lugar de repetir decenas de líneas.
Verá este patrón en aplicaciones grandes de código abierto como Now in Android. Por ahora, solo necesita conocer el objetivo: mantener los archivos de compilación pequeños y coherentes.
// feature/home/build.gradle.kts
plugins {
// One convention plugin sets up Android + Compose + Kotlin
id("myapp.android.feature")
}
android { namespace = "com.myapp.feature.home" }Mentalidad: piense en capas
El modelo mental más útil es el siguiente: las dependencias deben fluir hacia abajo. Las funcionalidades dependen de core; core no depende de las funcionalidades. El módulo :app se encuentra en la parte superior y depende de todo lo que necesita para ensamblar la aplicación.
Si mantiene esta dirección de forma coherente, el grafo de módulos seguirá siendo claro y evitará los ciclos, que explorará en una lección posterior.
// 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"))
}Comprobación rápida
¿Cuál de las siguientes es la ventaja más concreta y cotidiana que obtienen los equipos al modularizar una aplicación Android en crecimiento?
Resumen: por qué modularizar
Ha aprendido por qué los equipos dividen un monolito en módulos:
- Compilaciones más rápidas mediante ejecución en paralelo y almacenamiento en caché incremental
- Límites claros mediante
api/implementationyinternal - Reutilización de capas core, como el sistema de diseño y la red
- Responsabilidad del equipo con menos conflictos de combinación
También ha visto el coste (archivos de compilación adicionales) y la regla de oro: las dependencias fluyen hacia abajo, app -> feature -> core. A continuación, trazará los límites reales entre los módulos feature y core.
Preguntas frecuentes
¿La lección «Por qué modularizar» es gratis?
Sí — el texto completo de «Por qué modularizar» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de Android Academy, actualiza a CoddyKit PRO. El curso de Android Academy incluye 4 lecciones en total.
¿Qué aprenderé en «Por qué modularizar»?
Velocidad de compilación, responsabilidad y reutilización Practicas Android Academy con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar Android Academy?
No se requiere experiencia previa. Android Academy en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 1 de 4.
¿Cuánto tiempo toma la lección «Por qué modularizar»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de Android Academy?
Sí. Cada lección de Android Academy incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- Por qué modularizar
- Módulos de funcionalidades y del núcleo
- Gestión de dependencias entre módulos
- Navegación entre módulos