5 estrategias para facilitar el desarrollo de aplicaciones móviles

Eres un desarrollador de software y sabes bien que las apps paupérrimas abundan. Que las mediocres, las decentes y las buenas "a secas", también caen a cántaros. Pero ahora pregúntate: ¿Cuántas aplicaciones consideras excepcionales y referentes en su ramo? El número te puede resultar desalentador.

 

¿Desalentador? Eso lo fuese si no pudieras hacer nada al respecto. Velo de esta manera: El negocio de las soluciones móviles está sumamente competido. Con millones de aplicaciones disponibles, es una realidad que cada día el mercado se vuelve más saturado de lo que ya está; pero si como desarrollador haces tu parte bien, –y la idea y ejecución del negocio acompañan–, se abre una única oportunidad para posicionarse entre la élite de un determinado sector de negocio. ¿Lo que debes hacer? Adoptar estrategias que te acerquen a dicho cometido. Hoy vamos a ver cinco muy puntuales.

1. Adopta buenas prácticas independientes del alcance del proyecto.

No porque el alcance inicial sea “corto”, y la aplicación inicial en sus funciones sea “sencilla” de desarrollar, debemos descuidar el buen hacer. Muchas apps se ahogan porque no pueden crecer al ritmo de los nuevos requerimientos. Recuerda que todo proyecto bien hecho aporta valor al negocio y es mucho más sano —hasta mentalmente—, cuando generas una arquitectura escalable.

Pero ojo. El caso contrario también es habitual: Proyectos demasiado robustos que han sido sobrepensados terminan siendo de un mantenimiento difícil y milimétrico, pues requieren un montón de consideraciones previas y dominio para que tu nueva funcionalidad o corrección se lleven a cabo. El que tengas el control de tu codebase y de su crecimiento o simplificación es indispensable.

Una clave es comprender que el scope cambia constantemente y el generar una arquitectura que considera sólo el contexto actual del negocio supone complicar la vida y el crecimiento de tu aplicación. Para tal efecto, siempre genera documentación técnica que te ayude a planificar y tener distintas perspectivas de la construcción de la aplicación y sus funcionalidades. Apóyate de tus compañeros desarrolladores; de arquitectos y de analistas —si cuentas con dichos roles en tu equipo— para generar y actualizar los documentos de la mejor manera. El beneficio de adoptar el hábito de la documentación te permitirá ver posibles límites y oportunidades conforme el negocio vaya evolucionando. ¡Verás que el esfuerzo de mantenerlo actualizado rendirá frutos y ayudará a que siempre tengas visibilidad de la salud de tu arquitectura!

2. Todo lo que se mide se puede mejorar.

Un principio muy presente en la administración, pero a veces olvidado en la programación. Para que realmente puedas llevar a tu aplicación al siguiente nivel pregúntate cosas como: ¿Tengo definidas las buenas prácticas de desarrollo? ¿Sé qué tan complejo es mi base de código? ¿Sé cuál es el rendimiento de mi aplicación más allá de mi propia percepción? ¿Sé qué tan segura es mi aplicación? Cuestionamientos así te ayudarán a saber de qué carece tu aplicativo y cómo puedes mejorar tu solución informática.

Es recomendable invertir en un analizador de código, herramientas que te permitan monitorear el performance. Contrata un servicio que analice tus binarios en búsqueda de vulnerabilidades. Implementa analíticas útiles. Todo esto te ayudará a generar métricas medibles para tu producto. Tener un contexto informado y real sobre la salud de tu aplicación defiende tu trabajo y da certeza a la unidad de negocio. Te permite saber qué pasos tomar a futuro y qué mejorar para futuras versiones. Al final siempre sabrás qué tanto has madurado tu producto a través del tiempo.

3. Implementa flujos de integración y entrega continua CI/CD.

 

Lo hemos vivido. Has terminado el desarrollo del sprint, y necesitas generar una nueva versión. Tienes que empaquetar tu código y subirlo a una plataforma de pruebas, para después tener que subir el nuevo build a la tienda. Tienes que iterar este proceso cuantas veces sea necesario por cuestiones de corrección de errores, mejoras, cambios de alcances y demás. Es tardado. Es tedioso. Te quita tiempo útil. Deja que una máquina lo haga. Invierte tiempo en ello cuando te sea posible y disfruta de un desarrollo con menos presiones.

 

Tip: Te recomiendo que generes junto con tu equipo un pipeline de entrega y que el stakeholder lo apruebe. Con esto definido, negocien el tiempo necesario para ir integrando poco a poco estos nuevos procesos dentro del flujo de desarrollo ya que si bien no es complejo, sí puede representarte un esfuerzo mayor si es la primera vez que te adentras en el mundo de la integración.

4. Asegura tu código con pruebas.

 

Los tiempos han cambiado y el área de QA no es la única responsable de asegurar la calidad en el producto. Y quizá nunca lo fue. Es una responsabilidad compartida.

Ten una base de pruebas unitarias, de UI e integración en la que tú puedas asegurarte de que tu código funciona como debe. Trabaja en una arquitectura basada en servicios en donde puedas modularizar las pruebas y hacerlas tan granulares como sea posible. Usa patrones de diseño que te permitan inyectar dichas pruebas, pues de otra manera, será difícil que cumplas con una cobertura mínima para tu código.

 

Bonus: Si tus pruebas maduran, puedes incluirlas como parte del proceso de CI/CD que te mencioné anteriormente, de manera que se genere una nueva versión sí y solo si las pruebas son satisfactorias. Esto genera un surplus de confianza en cada entregable y te ayuda a verificar escenarios comunes antes de que te los reporten en pruebas, o que se vayan a producción sin que te des cuenta.

5. Piensa modular. Extrapola tu app.

Un escenario así es más común de lo que piensas: Has madurado tu aplicación, estás contento y de repente sale "un nuevo proyecto". Y como es un set de requerimientos totalmente distintos… bueno, tú y tu equipo piensan que tienen que empezar desde cero.

No tiene por qué ser así si modularizas los componentes que conforman a una app.

Crea paquetes de funcionalidades que puedas exportar. Por ejemplo, el llamado a un REST API o un gestor de base de datos son módulos que muchas veces se repiten sin apenas cambios y que puedes reusar en todos los proyectos que tengas actualmente.

 

También está el caso en que ése nuevo proyecto es para un mismo cliente y quiere el mismo lenguaje de diseño. ¡Pues vaya! Si te lo piensas, desde un inicio puedes desarrollar controles genéricos parametrizables, para luego generar paquetes de estos y usarlos sin apenas cambios. ¿Lo bueno de ello? Si hay algún bug o error, puedes corregir la fuente y con ello el error común que tenían todas tus apps. En un mediano plazo, verás que te puedes concentrar más en cumplir los objetivos del negocio en lugar de retrabajar los componentes y módulos.

 

Todo lo mencionado en este punto lo puedes ir trabajando por separado e irlos reemplazando en tus proyectos gradualmente.

Reflexión final

Si contemplas estas estrategias para lograr una arquitectura sostenible, e iteras sobre ellas, verás que naturalmente el devenir de tu ciclo de desarrollo te llevará a entregar una aplicación enfocada en el negocio y no en "las minucias de lo que conlleva realizar un desarrollo".