La importancia de las arquitecturas modulares en las aplicaciones móviles

Cuando se desarrolla una aplicación móvil es importante plantear bien su arquitectura técnica desde un inicio. A menudo muchas empresas se suelen centrar únicamente en aspectos como la experiencia de usuario, la usabilidad o el diseño, pero se suele dejar de lado la calidad del código o conceptos como mantenibilidad y escalabilidad, entre otros.

El resultado es una aplicación que inicialmente cumple las expectativas tanto de la propia empresa como de los usuarios finales, pero que a largo plazo se convierte en algo difícil de mantener, difícil de extender con nuevas funcionalidades y un proyecto en el que nadie quiere trabajar. En este artículo vamos a intentar analizar estas situaciones y cómo intentar evitarlas.

Una arquitectura es un conjunto de elementos y decisiones que definen cómo debe ser (y evolucionar) la estructura interna del código de una aplicación. Este concepto no es específico de las aplicaciones móviles sino que hace muchos años que está presente en muchos proyectos de software de cualquier tecnología.

En el caso concreto de las apps para iOS y Android, una arquitectura es la forma en que se estructuran las diferentes vistas, el código asociado a las mismas, los recursos gráficos, la lógica de negocio, los modelos de datos, la comunicación con servicios y bases de datos y la persistencia de datos, entre otros. También describe cómo se tienen que comunicar los diferentes elementos que forman parte de la estructura de una aplicación.

Es bastante habitual que en las aplicaciones móviles no se tenga tan en cuenta el diseño técnico sino que se primen otros aspectos. Es importante no pasar por alto cómo puede beneficiar una arquitectura modular a una aplicación móvil si el proyecto es medianamente grande. En el caso de aplicaciones más pequeñas, el uso de este tipo de arquitecturas sería considerado sobre ingeniería.

Para entenderlo, lo mejor es utilizar un ejemplo de la vida cotidiana: imaginemos que acabas de adquirir un terreno y quieres construir una casa en él. Hoy en día hay una gran variedad de opciones: casas prefabricadas, por módulos, construcción tradicional, etc.

Cuando uno se dispone a fabricar una casa o a comprar una que ya esté hecha, se fija en varios aspectos como pueden ser: tipo de materiales que se van a utilizar, calidad de los mismos, coste que representan para el conjunto de la obra, durabilidad y otros temas de mayor o menor interés.

Según las elecciones que se realicen, la casa que construyamos será una casa de lujo o una casa normal, durará 10 años o durará 200, etc. No significa que una sea mejor que la otra, sino que debemos tener en cuenta la cantidad de años que queremos vivir en ella o si tenemos pensado renovarla por completo con el paso del tiempo. Tenemos que asegurarnos de que el proyecto cumple nuestras expectativas.

Si sólo nos centramos en que quede bonita y sea funcional pero no tenemos en cuenta elementos clave como los cimientos, la calidad de las paredes y demás, seguramente tendremos problemas graves a medida que pasemos tiempo viviendo en esa vivienda: humedades, ruidos del exterior, goteras… y un sinfín de problemas.

¿Te imaginas una casa donde el váter esté en la cocina y el baño tenga un horno? Seguro que no vivirías en esa vivienda o como mínimo no podrías llamarlo hogar. Pero con un código no somos capaces de ver estas cosas si no tenemos conocimiento técnico; seguramente en tu aplicación tengas un horno en el baño.

Podemos tener una aplicación que sea bonita y funcional para su lanzamiento, pero por dentro el código puede no ser óptimo y tener muchas funcionalidades acopladas. En este escenario, extender ese mismo código con nuevas funciones o mantenerlo y buscar sus errores para solucionarlos se convierte cada vez en una tarea más difícil. Siguiendo el ejemplo anterior, reubicar el váter en el baño y el horno en la cocina no es tan simple como mover los elementos de sitio, sino que requieren cambiar gran parte de la instalación.

Es un factor que no sólo impacta al proyecto sino también a la rotación del personal técnico.

Que las arquitecturas no se piensen bien desde un principio no sólo provoca problemas para los desarrolladores, sino también para las propias empresas. Cuando un proyecto no se ha planteado bien desde un principio y se le pide a alguien que siga extendiendo su funcionamiento, al final acaba generando frustración porque las cosas van cada vez peor. Es muy difícil estructurar algo que inicialmente ya estaba mal planteado, por muchas horas que se le dediquen a refactorizar código y a reescribir ciertas partes.

Esta frustración suele acabar en problemas entre miembros del equipo (habitualmente entre personas técnicas y no técnicas), por la incapacidad de transmitir y hacer entender a los stakeholders que la arquitectura de la aplicación no se planteó bien desde el principio. Al final, como todo en la vida cuando algo no funciona, se acaba rompiendo por completo y las personas se acaban marchando. Cada vez que una persona del equipo se va, no sólo se va un recurso sino que se acaba marchando todo el conocimiento y la experiencia de esa persona.

Suele ser habitual pensar que con una persona más senior o con más experiencia solucionaremos el problema, ya que reescribirá partes de código que no estén bien y así ya no habrá frustración. Pero normalmente se consigue el efecto contrario: cuanta más experiencia tiene un profesional, más fácilmente se da cuenta de los problemas estructurales de una aplicación y seguramente acabe abandonando el barco antes que un perfil más junior, que tardará más tiempo en percatarse de la situación.

Es un pez que se muerde la cola, mientras los usuarios finales siguen esperando actualizaciones con nuevas funciones y correcciones de errores que nunca llegan.

La única solución posible pasa por reescribir en su totalidad la aplicación, pero cambiando el proceso. Si no tuviste en cuenta el diseño técnico cuando se empezó el proyecto, es el momento de hacerlo si decides empezar de cero. Si intentas reescribir partes o solucionar algunos pequeños defectos, la base del problema siempre estará ahí. Es como intentar solucionar un problema de convivencia sin que ambas partes reconozcan sus errores con sinceridad, volverá a aflorar de nuevo con el tiempo.

Hoy en día hay una tendencia en auge: las arquitecturas modulares. No son una moda pasajera sin más, porque las arquitecturas modulares vienen a solucionar dos problemas principales: la mantenibilidad y la escalabilidad. Veamos cómo lo hacen.

Una arquitectura modular es aquella que permite dividir una aplicación en varios módulos. Un módulo es un subconjunto de una aplicación que tiene:

• Una responsabilidad única, sólo una
• Un comportamiento funcional determinado y ninguno más
• La capacidad de comunicarse con otros módulos pero sin conocerlos por completo
• La capacidad de cambiar su interior sin afectar al exterior

Este tipo de arquitecturas utilizan una técnica llamada divide y vencerás, que consiste en dividir un problema muy grande (una gran aplicación) en fragmentos muy pequeños y específicos. De esta forma, cada vez que se hace uno de estos módulos es como empezar un proyecto de cero: si algo no funciona bien, puedes hacerlo de nuevo.

La principal diferencia con una arquitectura tradicional es que los distintos módulos pueden usarse y comunicarse entre ellos, pero no deben conocerse. De esta forma, es relativamente sencillo cambiar una pieza que no funciona por otra, ya que el resto de piezas sabrán comunicarse con la nueva de inmediato. A nivel técnico, la descripción de esta arquitectura se dice que sigue los principios SOLID, de los que seguro has oído hablar con anterioridad.

Como todo en la vida, las arquitecturas modulares tienen ventajas pero también inconvenientes. Veamos cuáles son:

Ventajas más relevantes

• Permiten rehacer partes que no funcionan sin afectar al resto.
• Permiten paralelizar más el desarrollo una vez que la base técnica está asentada.
• Facilitan el mantenimiento al estar dividido en piezas más pequeñas y menos complejas.
• Mejoran la felicidad del equipo a largo plazo ya que no generan tanta frustración.
• Permiten adaptarse rápidamente a nuevas funcionalidades de los sistemas operativos (p.ej. los “App Clips” recientemente anunciados por Apple).

Inconvenientes más relevantes

• Requieren un mayor esfuerzo inicial: la inversión económica que necesitan con respecto a una arquitectura tradicional es bastante más elevada. Principalmente porque se necesitan perfiles con mucha experiencia y se debe dedicar mucho tiempo a escribir documentación técnica y a realizar análisis técnicos complejos que den soluciones a las necesidades de negocio a largo plazo.
• Requieren una monitorización constante: para evitar que se acabe distorsionando el planteamiento inicial, es fundamental monitorizar periódicamente el estado del código, que se cumplan las directrices marcadas, etc. Los equipos que suelen hacer estas tareas suelen denominarse oficinas técnicas. No es necesario que estén formados por muchas personas, pero sí es estrictamente necesario que existan.

En Opentrends tenemos una sólida experiencia desarrollando arquitecturas modulares para aplicaciones de grandes clientes. 

Si estás pensando en empezar un nuevo proyecto que va a tener un largo recorrido o tu empresa se encuentra en una situación como la que hemos descrito en este artículo (problemas de mantenibilidad, imposible añadir nuevas funciones, alta rotación de personal técnico, etc.), podemos ayudarte a evitar repetir de nuevo los mismos errores. Ponte en contacto con nosotros y estaremos encantados de ayudarte.