La importancia de la arquitectura – Parte 1 – Migración – Proyecto personal
Tue May 14 2024
Como lo mencioné en la entrada anterior, voy a estar realizando una migración de una app en un monorepo. Esta app está hecha con Angular y Express, el método o forma de almacenamiento no lo mencionó porque se está usando un almacenamiento de la info basada en ficheros, que almacenan la información en formato JSON.
Y la vamos a migrar a una app con Vue, pero mostrando las ventajas de realizar una migración cuando ya tienes o ya existe una arquitectura escalable sobre la cual ya está basada la solución.
Experiencias previas
Bueno… dentro de la experiencia que tengo y el tiempo laborando; me ha tocado ver, experimentar y realizar varios tipos de migraciones.
Pero antes de comenzar a explicar algunas de las experiencias que he tenido… pongamos en contexto parte de, la palabra o acción de “migración”. De aceurdo con la página NetApp en su artículo: ¿Qué es una migración de datos?, describen lo siguiente:
“La migración de datos es el proceso de mover datos de una ubicación a otra, de un formato a otro o de una aplicación a otra. Normalmente, esto es resultado de la introducción de un nuevo sistema o ubicación para los datos“
Bien pues esta definición puede aplicar para los siguientes casos…
1.- Actualizaciones de versiones y Breaking changes
Desde la iniciación dentro del desarrollo web, me enfoque con Angular, un framework (herramienta) para realizar SPAs (Single Page Applications o Aplicaciones de una sola página en español) y me gustó por su enfoque tan robusto y su forma de hacer las cosas, ya que es muy “atado” al hacer las cosas bien; o bueno, al menos eso pienso.
Durante el desarrollo, se volvío algo común realizar actualizaciones de esta herramienta, principalmente porque su cadencia para lanzar nuevas versiones, tanto con solución de errores como con fallos de seguridad y nuevas caracteristicas, es de cada 6 meses. Y por supuesto, con estas nuevas caracteristicas y actualizaciones pues surgen cambios, cambios de esos en los cuales en ocaciones le tienes que meter mano al código para que funcione con la actualización o por alguna configuración necesaria. Y afortunadamente el equipo de Angular con cada versión, se actualiza su CLI (Command Line Interface o Interfaz de línea de comandos) que te permite ejecutar algunas instrucciones desde la terminal para poder manipular el proyecto; y por supuesto “automatizar” la corrección o implementación de estos cambios.
Desafortunadamente… no todas, o más bien son muy pocas, las herramientas que poseén esta característica que te ayuda en la automatización.
Pero hay cambios los cuales son importantes… A estos cambios se les demonia Breaking Changes, y también no siempre se pueden hacer de forma automatica con las herramientas que se proporicionan ya que no son tan sencillos de realizar; ya que con ellos se puede o se rompe algo, a este tipo de modificaciones algo especiales se les llama en ocaciones: No retrocompatibles, ya que si se realiza la modificación si o si algo va a fallar y se tienen que realizar los cambios completos y no parcialmente.
Es similar a cuando se te descompone algo y tratas de repararlo con piezas que no son las adecuadas y por ende, no funciona al 100% o bien no sirve.
En fin, me ha tocado estar metiendole mano a este tipo de actualizaciones, un poco más a las que se pueden hacer de forma automatica y no tanto a las que son cruciales pero de cualquier forma son utiles porque ayudan a aprender y ganar experiencia. Y para estás pocas ocasiones que me ha tocado entrar en las cruciales, son cambios tan grandes por el tamaño de las aplicaciones o por el impacto que tienen o bien porque al proyecto no se le daba cariño y estaba muy muy pero muy atrasado. Algunas son fáciles, otras algo complicadas, unas muy complejas pero todas tienen algo muy en común que puede facilitar esta tarea.
2.- “Actualizaciones/Migraciones entre lenguajes”
Ya que la mayor parte de casos en donde he visto y trabajado con estos casos es en Front-End, aunque no es excluyente de Back-End, ya que también lo he tocado, junto con el desarrollo de módulos y también como lo comenté entre las entradas recientes, en migraciones de proyectos completos; en donde literalmente es cambiar de lenguaje.
Eso si, únicamente a sido todo de algo X a TS…
Lo más fácil pero tedioso que he tenido que hacer, no ha sido como tal una migración pero se siente como; es agregar tipos o tipado a un proyecto, es decir definir explicitamente los tipos de datos o entidades a las cuales pertenecen las variables.
3.- Actualizaciones de módulos
La siguiente ha sido con la parte de módulos, en esta si fue pasarlos de JS a TS principalmente, y ya como extra agregarle tipos. Y porque los módulos? Sencillamente pues para mejorar la experiencia de desarrollo y ya que personalmente no me gusta fiarme de lo que diga el compilador de TS para la definición de los tipos y por las practicas o estándares para poder seguir con el mismo estilo de código.
También gracias a ello, y a mi perfeccionismo de que, no me gusta agregar o usar dependencias innecesarias o duplicadas, pues he podido resolver problemas de compatibilidad o implementación que algunas de las dependencia causan en ocasiones.
4.- Actualizaciones de módulos a monorepositorios
Esta parte si bien no ha sido muuuy pesada, al inicio si me enfrente a la parte de la organización, los cambios, la escalabilidad, etc… y principalmente como estaba muy enfocado a hacer ciertas cosas que estabán relacionadas entre si pero que a su vez no se debían mezclar y que era muy complicado realizar cambios, depuraciones y agregar nuevas caracteristicas debido al acoplamiento.
Y por último pero no menos importante: el historial de cambios en Git, ya que nunca lo habia pensado ni intentado pero de acuerdo con las referencias y las formas o enfoques de poder realizarlo… si se veían muy complicadas, o al menos sin practica o sin conocimiento de saber que se estaba haciendo a gran profundidad.
5.- Cambios de frameworks
Esta otra, no me ha tocado ser el responsable de pero, tuve la oportunidad de conocer a alguien que lideraba el desarrollo de un proyecto completamente en JS y que migró no solo a TS, sino también a una nueva versión del framework sobre la cual estaba construida… y la verdad mis respetos porque considero que no fue una tarea fácil; pero también que, al ver el cambio tan grande entre el proyecto que conocí hasta el proyecto que logre ver un tiempo después… uuuffff…. claro que ahora sé y conozco que debilidades se pudieron haber atacado a la par y ahora que soy Staff, si bien no tengo influencia en la toma de decisiones puedo apoyar con las ideas o posibles soluciones que pueden ser de ayuda para proyectos así.
Y por último… la migración de otro proyecto que si bien, este si estaba en TS, no tenia una arquitectura clara o definida como tal… a la cual era como un laberinto el estar tocando y para extraer las reglas de negocio me imagino que también fue complicado y aun más el documentarlas.
Y esto que tiene que ver? o a donde vá todo esto? Sencillamente todo esto en cierto aspecto dirige y recae en la falta de una arquitectura, del alto acoplamiento y de la deuda técnica que se va acumulando con el tiempo… y peor aún, en la cuestión del onboarding a alguien nuevo y sin experiencia en el desarrollo; hace que esto se vuelva bastante pesado y que no se entienda que se está haciendo o el porque.
Hasta ahorita únicamente he comentado el contexto y antedecente para poder aclarar el porque de lo que vamos a hacer o a realizar un poco más adelante y ver el porque de la importancia de la arquitectura, como lo menciono… Y de sus tantas ventajas de aplicar este aspecto a nuestros proyectos y mejor aún cuando tiene las o algunas de las caracteristicas que mencionaremos en las siguientes entradas.
Por el momento y a falta tanto de evidencia, como de tiempo y creatividad para poder explicarme y aclarar las pocas o muchas dudas que puedan llevar a salir cuando escribo las sucesivas entradas, me despido por el día de hoy pero espero poder formarme y hacerme del hábito de escribir aún más seguido y poder compartir parte de mi experiencia y algunas de las cosas que voy haciendo.
Happy coding! 🖖