Al inicio de nuestras vidas como desarrolladores, las arquitecturas de software no suelen ser un tema prioritario. En este artículo veremos si de verdad son necesarias o no, pero antes que cualquier cosa, es imprescindible conocer qué es una arquitectura de software y la diferencia respecto a un patrón de diseño.

¿Qué es un patrón de diseño?

Antes de definir una arquitectura, es vital saber qué es un patrón de diseño, ya que algunas veces se pueden llegar a confundir. 

Un patrón de diseño es una solución estandarizada a un problema común. El objetivo es diseñar un código reutilizable o replicado.

Los patrones de diseño pueden ser en código, por ejemplo con Kotlin, pueden venir prefabricados por librerías, o incluso implementarse a nivel de diseño de vista.

El patrón singleton es el ejemplo por excelencia, ya que básicamente soluciona la concurrencia de datos en una sola instancia. Pero un patrón, por más complejo que sea, no conforma por sí solo una arquitectura. Sin embargo, un conjunto de patrones sí lo hace.

Finalmente decir que un patrón de diseño puede identificarse por su utilidad, ya que son hechos para crear instancias, para estructurar clases o para comunicar objetos.

¿Qué es una arquitectura?

Es un conjunto de soluciones que estructuran un proyecto de forma ordenada. Contempla varias cosas para su formación, como patrones de diseño, librerías, principios de programación, organización de carpetas, clases, y desde luego, todo pensando en la plataforma que se vaya a usar, por ejemplo, Android.

Una arquitectura también se ve directamente influenciada por la plataforma y recursos objetivos. Es decir, un lenguaje de programación, el sistema operativo y los dispositivos donde se ejecutará el software, determinarán parte del esquema a definir.

Muy importante aprovechar para mencionar que las arquitecturas de software no son plantillas. ¿A qué me refiero? Muchas veces encontramos proyectos que presumen tener cierta arquitectura, solo por tener ciertos nombres en sus clases y carpetas, o por usar cierta librería. Eso pasa porque se confunde la estructura  de un proyecto con la arquitectura.

Hago esa aclaración porque como veremos más adelante, podemos adaptar las arquitecturas y ver proyectos con diferentes organizaciones en apariencia, pero de iguales conceptos a la hora de comunicar sus clases. En ese sentido, las arquitecturas llevan más peso en el respeto de sus principios, que en la organización o alineamientos de nombramiento.

Origen de las arquitecturas de software, ¿realmente son necesarias?

Antes del uso de arquitecturas, la creación de apps grandes, o en constante evolución, resultaban cada vez más propensas a errores y a una mayor inversión de tiempo para modificar algo.

¿Por qué pasa eso? 

Bueno, de hecho eso sigue siendo muy común hoy en día, debido a que todos los desarrolladores, cuando recién aprendemos a programar apps para Android, lo que más nos importa es saber cómo crear un formulario, cómo conectarnos a una base de datos, cómo cambiarle los colores, icono, cómo subirla a la play store… 

En fin, eso es normal, pero a medida que dominamos esos temas básicos, y comenzamos a crear aplicaciones cada vez más grandes y complejas, nos topamos con nuevos retos, pues comenzamos a notar que si ponemos toda la lógica en las actividades o fragmentos, rápidamente iremos repitiendo código, además de ver como las clases comienzan a crecer sin control. Es muy fácil rebasar las 300 o 400 lineas de código en una sola actividad si simplemente ponemos todo el código ahí, ya sea para acceder a la vista, a una base de datos, a crear funciones que cambien un formato, o incluso intentar comunicarnos con otra activity / fragment, puede generar mucho código repetitivo.

El mayor reto viene cuando queremos modificar el código, porque si todo se hiciera una sola vez, y por alguna razón nuestro código no tuviera bugs (BUG = BaGS) en el futuro (bugs es el término para referirse a los errores de código en un software). Bueno, si solo fuera crear el código una vez, podríamos pensar que no está mal crear apps sin arquitecturas. Desde ese punto de vista no hay una necesitad inmediata.

Pero lamentablemente, ese mundo de caramelos no existe. Lo cierto es que las aplicaciones que se usan en el mundo real siempre tendrán cambios, o en el mejor de los casos, escaladas.

¿A qué me refiero con escaladas, y por qué digo que en el mejor de los casos? Escalada, en términos de programación, se refiere a que una app tenga cada vez más vistas, y más funciones. En términos de arquitecturas de software, se refiere a tener cada vez más módulos, pero ya profundizaremos en eso más adelante. 

Y en cuanto a por qué escalar es el mejor de los casos, bueno, porque eso significa que nuestra app está en crecimiento, lo cual se traduce en más trabajo para nosotros, y por ende, en más ingresos, o en una justificación de nuestro puesto de trabajo. 

Y debido a que las apps cambian y crecen constantemente, eso repercute en el tiempo que invertimos, porque cada vez es más difícil modificar algo con cientos o miles de líneas de código. Incluso si todo el código es nuestro, es fácil olvidar por qué hicimos X función, o X validación. Y si el nuevo código choca con algo de lo ya existente, ¡boom! Un nuevo bug ha sido creado.

Algunos programadores se refieren a este fenómeno como el efecto Jenga, ese juego que conforme avanza se vuelve más inestable hasta que en un punto todo falla. 

Ojalá nuestros problemas se redujeran a un solo Jenga. Porque todo lo que he dicho es pensando en una sola vista. La realidad es que las apps suelen tener varias pantallas y cada una representaría un Jenga, por lo que ahora es más fácil ver con claridad que si te piden un cambio que digamos, afecta a como se consulta la base de datos, o qué parámetros se pasan de una pantalla a otra, por poner unos ejemplos, no solamente debemos tener cuidado de modificar esa clase gigante (pensando que seguimos trabajando sin arquitecturas), sino que debemos repetir el proceso en cada pantalla.

Alguien podría pensar que si encuentras la solución correcta, luego sería fácil solo copiar y pegar, pero lo cierto es que cada vista de nuestra app tiene sus propias validaciones, su propio procesamiento de datos, sus propios comportamientos. Eso hace que muchas veces las soluciones se deban acoplar a cada vista. Es copiar, pegar y adaptar. 

Además de todo lo anterior, muchas veces pasa que ante una app que tiene, digamos, 40 vistas. Algunos cambios o nuevas funciones solo deben afectar a unas cuantas vistas, por lo que es fácil olvidar alguna o como hacíamos referencia hace un momento, adaptar de forma incompleta en alguna de esas vistas afectadas.

Ahora piensa que no trabajas solo, que estás en un equipo de desarrollo. Cada programador tendrá una idea diferente de cómo solucionar un código, por lo que además de lo anteriormente mencionado, imagina que te piden modificar algo que hizo otro programador. Las probabilidades de que tú entiendas a la perfección cómo y por qué existe cada línea de código, es realmente baja. No solamente necesitarás más tiempo en tratar de entender la estructura y lógica del otro programador, sino que también aumentarás la complejidad del proyecto, porque ahora esa vista tiene 2 lógicas funcionando, algo que con el paso del tiempo va haciendo que los proyectos tengan ese tipo de problemas con más frecuencia, aumentando así ese es el efecto Jenga que comentábamos en líneas anteriores.

Podríamos seguir aquí profundizando en todos los problemas que representa el no usar arquitecturas, pero con lo planteado hasta ahora puedes entender por qué es vital el implementar una solución definitiva a nuestra manera de crear código para las aplicaciones de nuestro trabajo.

Algunos programadores a lo máximo que llegan es a intentar organizar sus proyectos, pero eso siempre resulta ineficiente. Al final te dejaré un enlace de un curso práctico dónde entenderemos qué es una arquitectura, qué variantes hay y desde luego, cómo implementarlas a nivel de código.

Resumen

En conclusión, las arquitecturas de software son totalmente necesarias para cualquier proyecto serio que inevitablemente tendrá cambios en sus funciones y comportamientos, o crecimiento con nuevas vistas y módulos.

En caso de no tener una arquitectura implementada, las consecuencias serán costosas a nivel de recursos humanos y monetarios.

Si te interesa saber más sobre las ventajas y desventajas de usar arquitecturas de software, te dejo el siguiente articulo: ¿Qué arquitecturas para Android hay? Ventajas y desventajas

Y si deseas saber elegir qué arquitecturas de software para Android usar, sin duda debes ver este artículo: ¿Cuál es la mejor arquitectura para Android con Kotlin?

Más información del curso de arquitecturas de software para Android, aquí: Curso de Arquitecturas para Android

Fuerte abrazo!

Ing. Alain Nicolás Tello.

Cursos ANT.