6 decisiones que todo ingeniero Android debe tomar cuando desarrolla

![[06-attachments/talks/2022-02-17-6-decisiones-que-todo-ingeniero-android-debe-tomar-cuando-desarrolla/2022-02-17-6-decisiones-android-debe-tomar.png]]

En esta charla revisamos las decisiones técnicas que marcan el rumbo (y la salud) de cualquier equipo Android. Porque escribir código es una parte… pero tomar buenas decisiones es lo que realmente hace la diferencia.

1. Arquitectura: ¿qué estructura soporta tu app?

• Clean Architecture, MVVM, MVI, hexagonal… no importa solo el nombre.
• Lo importante es la claridad de responsabilidades, la separación de capas y la facilidad para testear.
• Decisión: ¿tu arquitectura es accidental o intencional?

2. Tiempos de build: ¿cuánto tiempo estás perdiendo?

• Build lento = feedback lento = frustración asegurada.
• Usá herramientas como Gradle Profiler para entender cuellos de botella.
• Decisión: ¿tenés un objetivo concreto de build time?

3. Modularización: ¿tu app escala o se rompe?

• Módulos pequeños, desacoplados, testeables y reutilizables.
• Permite builds paralelos, ownership por features y menos conflictos.
• Decisión: ¿qué criterio usás para dividir tu app?

4. System design: ¿entendés cómo funciona tu sistema?

• Diagrama de flujos, contratos entre capas, separación de contexto.
• Diseño explícito, no emergente por accidente.
• Decisión: ¿tenés un diseño sistémico o una suma de pantallas?

5. Proceso de release: ¿es doloroso o automático?

• Versionado, changelog, validaciones, pruebas, publicación.
• Lo ideal: un botón. Lo mínimo: que no sea un drama.
• Decisión: ¿tu release depende de humanos o de procesos?

6. Métricas: ¿sabés cómo va tu app?

• Crash rate, ANRs, startup time, screen load, App Size, etc.
• Métricas técnicas y de negocio. Medí para decidir.
• Decisión: ¿medís lo que importa o solo lo que es fácil?

Bonus: Testing

• Unit, integration, end-to-end, contract tests.
• No testear es caro. Y testear mal, también.
• Decisión: ¿qué parte de tu app no se puede romper jamás? Empezá por ahí.

Key Takeaways

1. Las decisiones técnicas son decisiones de producto a largo plazo.
2. Cada uno de estos puntos puede acelerar (o frenar) el crecimiento del equipo.
3. Lo importante no es la decisión perfecta, sino tomarla con intención y revisarla.
4. Sin métricas ni procesos, el caos se normaliza.
5. Testing no es un bonus. Es parte del juego.

Recursos recomendados

• Gradle Profiler
• Android App Modularization Guide
• Play Console – Métricas técnicas
• Effective Android Testing

Conclusión

Estas seis decisiones no son optativas. Las vas a tomar igual, aunque no te des cuenta. La diferencia está en hacerlo a conciencia. Porque cuando tu app falla, no suele ser por una pantalla… sino por una decisión mal tomada.