¿Cómo abordas una migración de plataforma importante, como mover una app grande a Jetpack Compose?

#Lo que el entrevistador realmente está evaluando

Cuando alguien pregunta cómo abordarías una migración como esta, no está comprobando si conoces el modelo mental de Compose — esa es una pregunta técnica aparte. Está comprobando si piensas en las migraciones como un problema de gestión de riesgo y organización antes que como un problema técnico. Una respuesta floja describe pantallas; una respuesta sólida describe la secuenciación, un plan de reversión, cómo el equipo sigue entregando funciones sobre la pila antigua mientras la nueva se pone en marcha, y cómo medirías si la migración realmente se está pagando sola. Esa es la forma a la que intento llegar en los primeros treinta segundos de la respuesta, porque comunica seniority mucho más rápido que cualquier detalle de la API de Compose.

#Auditar antes de anunciar nada

Lo primero que hago en la práctica — antes de que se publique una sola línea de Compose — es construir un inventario honesto de la app: cuántas pantallas hay, cuáles tienen mucho tráfico frente a cuáles apenas se tocan, cuáles descansan sobre Views personalizadas con años de casos límite sin documentar, cuáles podría abordar con seguridad un ingeniero junior frente a cuáles solo deberían tocar las dos personas que entienden de verdad el flujo de checkout. Clasifico todo en una matriz simple: riesgo de negocio si algo se rompe, y complejidad técnica de conversión. Ese mapa es lo que convierte "deberíamos migrar a Compose" de un eslogan en un plan, y suele ser el artefacto que consigue el sí de un VP de Ingeniería escéptico, porque demuestra que ya pensaste en qué podría salir mal.

#Elegir una cabeza de playa con el patrón "strangler fig"

Nunca propongo reescribir la app de una sola pasada — es la forma más común en que estos esfuerzos mueren, porque una reescritura de una sola vez significa cero valor incremental para el negocio durante los trimestres que dure, y cualquier retraso se convierte en un argumento existencial contra toda la iniciativa. En su lugar uso el enfoque "strangler fig": envuelvo primero un puñado de pantallas de bajo riesgo y autocontenidas en Compose — una pantalla de ajustes, un perfil, algo con usuarios reales pero bajo radio de impacto — usando ComposeView para alojarlas dentro de la Activity o Fragment existente, y AndroidView a la inversa cuando una View personalizada aún no migrada necesita vivir dentro de una pantalla ya construida en Compose. Esa capa de interoperabilidad no es un parche; es el mecanismo completo que permite que ambos mundos convivan durante el año o dos que dura de verdad una migración real.

#Justificar el negocio con números, no con convicción

A los ingenieros les entusiasma el modelo declarativo de Compose; a los directores de ingeniería les entusiasma la evidencia. Por eso trato las primeras pantallas piloto como un experimento instrumentado: impacto en el tiempo de build, delta en el tamaño del APK, tasa de crash-free antes y después y — el número que realmente mueve las conversaciones de presupuesto — cuánto tardó una funcionalidad comparable en construirse y pasar QA en la pila antigua frente a la nueva. En cuanto puedes decir "la reescritura de ajustes tardó un treinta por ciento menos de tiempo de calendario y necesitó la mitad de pasadas de QA manual porque pudimos previsualizar y hacer screenshot-testing de la UI sin levantar el emulador", has convertido una preferencia estética en una iniciativa financiada.

#Construir el músculo antes de escalar el esfuerzo

Una migración que depende de dos ingenieros que saben Compose no escala más allá de esas dos personas. En paralelo al piloto, invierto en una librería de componentes compartida — los botones, tarjetas y primitivas de layout que todo el equipo va a usar — para que el quinto ingeniero que toque Compose esté ensamblando piezas ya validadas, no re-derivando desde cero las reglas de estabilidad y hoisting de estado. Programo pair programming de forma deliberada, organizo talleres internos cortos sobre las trampas que muerden a todo el mundo una vez — parámetros de lista inestables, recordar las cosas equivocadas, sorpresas de recomposición — y hago que el code review sea el mecanismo que hace cumplir los patrones acordados, en lugar de depender de la memoria tribal del equipo.

#Barreras de protección que mantienen la app publicable todo el tiempo

Cada pantalla migrada se publica detrás de un feature flag y se despliega primero a un pequeño porcentaje de producción, porque Compose cambia el renderizado, y el modo de fallo del que hay que protegerse es una regresión visual sutil o una regresión de rendimiento específica de Compose — jank en un dispositivo de gama baja — que nunca aparece en los teléfonos de prueba insignia del equipo. Mantengo baseline profiles y benchmarks de arranque y frame-timing en CI para que una regresión se detecte antes de hacer merge, no después de que aparezca un ticket de soporte, y mantengo una palanca explícita de reversión — apagar el flag, volver a la View — para cada pantalla migrada durante al menos un ciclo de release.

#Cómo contaría esta historia en una entrevista

Si de verdad lideré una de estas migraciones, anclo la respuesta en una pantalla concreta, una métrica concreta y un momento concreto en el que el plan tuvo que doblarse — una regresión de rendimiento que atrapamos en canary, un stakeholder que quería saltarse el piloto e ir directo a la pantalla de inicio, un ingeniero junior que necesitó más pair programming del que había presupuestado. Los entrevistadores recuerdan mucho más las migraciones descritas como un proceso negociado y medido que una historia limpia y sin fricción — la fricción es justamente lo que demuestra que de verdad dirigiste una.