KISS en desarrollo móvil — qué es, el principio de simplicidad y cómo aplicarlo

¿Qué es KISS?

KISS (Keep It Simple, Stupid) es un principio de diseño que exige minimizar la complejidad del sistema. Fue formulado en la Marina de los EE.UU. en la década de 1960 por el ingeniero Kelly Johnson (Lockheed SR-71 Blackbird). Johnson insistía en que la aeronave debía poder ser reparada por un mecánico en el campo sin herramientas especiales — esa es la esencia de KISS.

En el desarrollo de software, KISS significa: una solución debe ser tan simple como sea posible, pero no más simple (la segunda parte de la frase atribuida a Albert Einstein). La simplicidad no es un sinónimo de primitivismo; una solución simple realiza la tarea con una redundancia mínima.

Un estudio de Google Research (2022) mostró que el tiempo medio de incorporación de un nuevo desarrollador es de 3 semanas en proyectos que siguen KISS frente a 10 semanas en proyectos con arquitectura excesiva. El código simple es una inversión en la velocidad de adaptación de los nuevos miembros del equipo.

Usa KISS como filtro: antes de agregar una nueva abstracción, pregúntate “¿resuelve esto un problema que existe hoy, o un problema que podría surgir en un año?” Si es lo segundo — no lo hagas.

KISS y la navaja de Occam

La navaja de Occam (siglo XIV) es un principio filosófico: “las entidades no deben multiplicarse sin necesidad”. En programación, esto significa: de dos soluciones que satisfacen igualmente los requisitos, elige la que tenga menos entidades (clases, módulos, dependencias). KISS es la implementación práctica de la navaja de Occam en el código.

La diferencia es que la navaja de Occam es un principio general del conocimiento, mientras que KISS es una práctica de ingeniería específica con resultados medibles: reducción de la complejidad ciclomática, menos líneas de código, menor tiempo de revisiones de código. Las métricas permiten evaluar objetivamente el cumplimiento de KISS.

Sigue esta métrica: el código se considera “suficientemente simple” si un nuevo desarrollador entiende el fragmento en un minuto sin comentarios. Si se necesita más tiempo — simplifica.

¿Por qué la simplicidad es crítica en el desarrollo móvil?

El desarrollo móvil tiene tres características que hacen que KISS sea especialmente importante: recursos limitados del dispositivo (memoria, CPU), actualizaciones frecuentes de las plataformas (iOS anualmente, Android trimestralmente) y la necesidad de entrega rápida de funcionalidades mediante CI/CD. El código complejo no puede mantener este ritmo.

Un análisis de Apple WWDC 2023: “Embrace Swift Generics” mostró que el proyecto iOS promedio contiene 40–60% de “código muerto” — abstracciones escritas “para el futuro” que nunca se utilizan. Este código no solo aumenta el tamaño del binario, sino que también ralentiza la compilación y complica la navegación. KISS lo previene: escribe solo lo que se necesita ahora.

Según el Android Developer Relations Report (2024), los proyectos con una baja proporción de código a pruebas (menos de 1:0.8) tienen un 67% más de errores en producción. El código complejo es más difícil de probar — esto es una amenaza directa a la calidad. La simplicidad es un requisito previo para una alta cobertura de pruebas.

Mide la complejidad de tu código a través de métricas: complejidad ciclomática — mantén cada método por debajo de 10, idealmente por debajo de 5. Usa Detekt (Android) o SwiftLint (iOS) para la verificación automatizada.

KISS vs overengineering: ejemplos prácticos

Arquitectura excesiva: demasiadas capas

El overengineering típico es crear una fábrica abstracta de repositorios en un proyecto con una sola fuente de datos. En lugar de una clase Repository simple, el desarrollador construye una cadena: RepositoryFactory → IRepository → BaseRepository → RepositoryImpl — para la hipotética posibilidad de cambiar la API a GraphQL.

Según la JetBrains Developer Survey (2023), el 43% de los desarrolladores Android admitieron haber eliminado una capa arquitectónica durante la refactorización porque nunca se usó. KISS dice: crea una abstracción cuando aparezca una segunda opción de implementación, no en previsión.

Comienza con una implementación concreta sin interfaz. Cuando aparezca una segunda fuente de datos — extrae la interfaz mediante refactorización (el IDE lo hará automáticamente). Esto es más rápido que escribir una interfaz por adelantado.

Grafos de inyección de dependencias sobredimensionados

Los frameworks de DI (Dagger, Hilt, Swinject) son herramientas potentes, pero a menudo provocan complejidad. Los desarrolladores crean un módulo separado para cada entidad, incluso si se usa en un solo lugar. Alternativa KISS: inyección manual por constructor para casos simples.

// Overengineering: módulo para un solo repositorio
@Module
object UserModule {
    @Provides
    fun provideUserRepo(): UserRepository = UserRepositoryImpl()
}

// KISS: inyección manual si solo hay un repositorio
class UserViewModel(
    private val repo: UserRepository = UserRepositoryImpl()
) { /* ... */ }

La inyección manual por constructor es el patrón DI más simple. No requiere generación de código, anotaciones ni módulos. Cambia a un framework de DI solo cuando el proyecto alcance 5+ pantallas y la inyección manual sea difícil de mantener.

¿Cómo aplicar KISS en Android e iOS?

KISS en Android: ViewModel y LiveData simples

El ViewModel de Android es una fuente frecuente de complejidad excesiva. Los desarrolladores agregan StateFlow, combine, flatMapLatest y cadenas de transformaciones donde bastaría con un simple MutableLiveData con postValue. KISS recomienda: comienza con la solución más simple (LiveData), complícala solo para una necesidad específica (restablecimiento de estado, debounce).

// KISS: ViewModel simple sin cadenas reactivas
class ProfileViewModel : ViewModel() {
    private val _name = MutableLiveData<String>()
    val name: LiveData<String> = _name

    fun loadUser(id: String) {
        viewModelScope.launch {
            _name.postValue(repo.getUser(id).name)
        }
    }
}

En este ejemplo, el ViewModel usa una corrutina para la solicitud asíncrona, LiveData para publicar el resultado. Sin StateFlow, sin combine — solo lo que realmente se necesita. Agrega StateFlow cuando se requiera un flujo de datos unidireccional (UDF) con estado explícito.

KISS en iOS: estructuras simples en lugar de clases

En iOS, el principio KISS se manifiesta prefiriendo structs a clases para los modelos de datos. Los structs son tipos de valor, no requieren gestión de memoria mediante ARC y son inmutables por defecto. Las clases se justifican solo cuando se necesita identidad (dos referencias al mismo objeto) o herencia.

// KISS: struct en lugar de class para el modelo
struct User: Codable {
    let id: Int
    let name: String
    let email: String
}

// Overengineering: class con init y deinit manuales
class UserClass: NSObject {
    let id: Int
    init(id: Int) { self.id = id }
}

El struct User obtiene automáticamente un init memberwise, conformidad con Equatable y Hashable (por todos los campos), inmutabilidad y seguridad en entornos multiproceso. Una clase requiere init manual, implementación de NSObject y es susceptible a condiciones de carrera a través del estado compartido.

Simplicidad en la capa de red

La capa de red es otra área donde KISS se viola con frecuencia. Los desarrolladores añaden una cadena de Interceptor de 5+ elementos, serialización mediante fábricas abstractas y mapeadores para cada endpoint. Solución KISS: una URLSession con configuración y una decodificación mediante Codable/JSON.

Según la Apple URLSession Programming Guide (2023), una capa de red simple con URLSession y Codable cubre el 95% de los escenarios de aplicaciones móviles. Las cadenas complejas de Interceptor son necesarias solo para casos específicos: renovación de tokens, registro, cifrado.

Comienza con una capa de red simple basada en URLSession + Codable. Agrega Interceptors según surjan necesidades reales, no “por si acaso”. Esto reduce el código de la capa de red en 2–3 veces.

Errores comunes al seguir KISS

Confundir simplicidad con primitivismo

La simplicidad no es lo mismo que el primitivismo. Una solución simple es una solución concisa y clara que resuelve la tarea sin redundancia. Una solución primitiva ignora las mejores prácticas y la arquitectura sólida. La diferencia es que una solución simple es fácil de extender, mientras que una primitiva no lo es.

Ejemplo: usar Activity como la única entidad para todas las pantallas es primitivismo, no simplicidad. La simplicidad es usar Navigation Component con diferentes Fragments para diferentes pantallas, pero sin abstracciones innecesarias. KISS no justifica una arquitectura pobre.

Pregúntate: ¿puede tu código cambiar al agregar una nueva funcionalidad? Si es así — la simplicidad es correcta. Si cada funcionalidad requiere reescribir todo — eso es primitivismo, refactoriza inmediatamente.

Ignorar patrones en nombre de KISS

Los patrones (MVVM, MVI, Coordinator) no son una complicación, sino una estructuración. KISS no prohíbe usar patrones arquitectónicos probados. Prohíbe su uso excesivo: tres patrones donde bastaría con uno. El punto óptimo es un patrón arquitectónico por proyecto y no más de 2–3 auxiliares (DI, Navigation).

Según el State of Mobile Architecture Report (2024), los proyectos que usan exactamente un patrón arquitectónico tienen un 34% menos de errores en el primer año de desarrollo que los proyectos “Frankenstein” que combinan 3+ patrones. Elige MVVM o MVI para un proyecto móvil — y mantenlo en todas las pantallas.

No mezcles MVVM y MVI en el mismo proyecto. Si el equipo eligió MVVM — todo el proyecto debe seguir MVVM. Las excepciones son módulos de funcionalidad individuales con su propia decisión arquitectónica, pero esto debe ser una elección consciente.