DEV Community: JaviCoronas

Cómo hacer un merge y no morir en el intento

JaviCoronas — Sat, 26 Aug 2023 11:56:38 +0000

Si trabajamos en el mundo del desarrollo de software pronto descubriremos que es proceso colaborativo y dinámico que implica la constante evolución de un proyecto a medida que se agregan nuevas funcionalidades y se corrigen errores. Durante este proceso tendremos que afrontar diferentes merges, proceso por el cual se combinan los cambios realizados en diferentes ramas del repositorio en una única versión consolidada.

Aunque los merges son esenciales para mantener un código base coherente, pueden volverse complicados y desafiantes, especialmente cuando trabajamos en proyectos complejos o nos enfrentamos ante una divergencia entre las ramas.

En este post, intentaré transmitir el cómo afrontar un difícil merge entre ramas y superar los desafíos asociados. Desde la planificación inicial hasta la resolución de conflictos y las pruebas exhaustivas, todo esto para garantizar que el proceso de merge sea lo más fluido y eficiente posible.

Afrontar un merge complejo puede parecer un desafío abrumador, pero con las estrategias y consejos adecuados, cualquier equipo de desarrollo puede enfrentar esta tarea con confianza y obtener resultados satisfactorios. ¡Acompáñame en este recorrido para poder afrontar de una mejor manera los infernales merges que a veces nos tocan!

Planificación y Comunicación: Preparándonos para un Merge exitoso

Imagina el merge como un proyecto de construcción. Antes de ponernos los cascos, tomar las herramientas y empezar a trabajar... ¡necesitamos un plan sólido y buena comunicación para evitar que todo se convierta en un enredo de piezas!

Diseñando nuestro plan de ataque

Es vital tomarnos un momento para planificar. Esto es como trazar un mapa antes de un emocionante viaje: nos ayuda a identificar rutas, puntos de referencia y posibles baches en el camino.

Pongámonos en contexto: cada rama tiene sus propias adiciones y ajustes. Planificar con anticipación el contexto de cada rama, nos permite comprender qué cambios se están realizando en cada rama, su funcionalidad raiz y cómo interactuaran entre sí cuando se fusionen.

El poder de comunicarse

La comunicación es la clave para cualquier relación exitosa. Antes de hacer cualquier movimiento, asegúrate de sincronizar con tus compañeros de equipo. Por suerte en proyectos de software solemos tener un registro completo sobre las diferentes funcionalidades desarrolladas, por quien y cuando se han realizado, pero si hay alguna duda, comunícate. Esto no solo evita sorpresas desagradables, sino que también fomenta un sentido de colaboración y trabajo en equipo.

El poder está en tus manos

Entonces, antes de pulsar ese botón de merge, asegúrate de haber trazado un plan, charlado con tus compañeros de equipo y organizado una pequeña fiesta de intercambio de conocimientos. En los cuales tendrás más localizadas las clases implicadas, funcionalidades clave que probar y además al hacerlo, estarás sentando las bases para un merge exitoso y sin estrés (espero).

En la próxima sección, exploraremos cómo enfrentar los temidos conflictos que pueden surgir durante un merge y cómo resolverlos como verdaderos héroes del desarrollo.

Resolución de conflictos: Navegando las aguas turbulentas del Merge

¡Ah, los conflictos! Son como los giros de guión en una película: pueden añadir intriga, pero también pueden generar un dolor de cabeza. Pero no te preocupes, conserva la calma y ten confianza confianza, sabías que iba a pasar.

Identificando los conflictos de la fiesta del merge

Imagina que estás en una fiesta y dos personas llegan luciendo la misma camisa. ¡Ups! Eso es un conflicto de moda. Del mismo modo, durante un merge, los conflictos pueden surgir cuando dos o más cambios compiten por el mismo pedazo de código. Normalemnte, nos entrentaremos a:

Conflictos de código: Cuando el mismo fragmento de código ha sido modificado en diferentes ramas.

Conflictos de archivos: Cuando dos ramas han modificado el mismo archivo y es necesario decidir cuál versión mantener.

Conflictos de dependencias: Cambios que afectan a las mismas dependencias, causando incompatibilidades.

Resolver como un profesional del Merge

Una vez que has identificado a los invitados no deseados (los conflictos), es hora de actuar. Aquí tienes dos enfoques principales:

Resolución manual: Este enfoque es como ser un mediador en la fiesta del merge. Revisas cada conflicto uno por uno, tomando decisiones sabias y manteniendo lo mejor de ambas partes. Asegúrate de entender el contexto y el propósito de cada cambio antes de tomar una decisión.

Herramientas de comparación y fusión: Sigamos con nuestra metáfora sobre moda. Piensa en esto como tener un asistente que te ayuda a decidir qué atuendo se ve mejor. Herramientas como diff y merge permiten comparar las diferencias entre versiones de código y combinar cambios de manera eficiente. Son especialmente útiles para cambios extensos o cuando los conflictos son difíciles de identificar manualmente. Los propios IDE traen potentes herramientas para facilitarnos esta labor. Úsalas a discreción, pa eso están, Manuel!

Tomando decisiones con sensatez

La resolución de conflictos es como un juego de ajedrez: cada movimiento debe ser estratégico. Aquí tienes algunos consejos para tomar decisiones informadas:

Comprender el propósito: Asegúrate de entender el propósito de cada cambio y cómo encaja en el panorama general del proyecto. Si has hecho un estudio previo de las funcionalidades que entran, que salen o que cambian, esto será trabajo de niños.

Considerar el impacto: Evalúa cómo cada decisión afectará a otras partes del código y a las funcionalidades existentes.

Solicitar opiniones: Puede que te encuentres con partes del código que no sepas de dónde vienen o para que sirven. No tengas miedo de pedir consejo a compañeros de equipo que han desarrollado esa parte.

Al abordar los conflictos con paciencia y estrategia, te conviertes en el director de la película, en la que el código se une sin problemas y todos los protagonistas (los cambios) encuentran su lugar perfecto.

Realiza todas las pruebas

Estamos deacuerdo en que cualquier proyecto de software implica que debemos trabajar en un pool de pruebas que sea capaz de probar todas nuestras piezas desarrolladas de forma individual (test unitarios) y también seamos capaces de probar funcionalidades completas (test integración).

En nuestro caso, durante el merge hemos tenido que ajustar estas pruebas. Hemos decidido qué partes pueden quedar obsoletas por los cambios al unir ambas partes y qué partes hay que conservar. Tras esto, no podemos lanzar nuestra película a los espectadores. Debemos repasar cada una de nuestras escenas (funcionalidades) para ser capaces de localizar/arreglar cualquier problema de última hora. Éste proceso es nuestro salvoconducto para que todo funcione como se espera.

Por lo tanto, con pruebas antes y después del merge, aseguramos que nuestro código y proyecto funcione como se espera.

Conclusión: Encarando los Merges con Confianza

Y así, cerramos esta exploración de cómo enfrentar los desafíos de los merges.

Hemos aprendido que un enfoque planificado y comunicativo es la base para un merge exitoso. La importancia de la planificación detallada y la comunicación destaca que, al trabajar juntos, los equipos pueden convertir incluso los merges más difíciles en un simple avance de nuestro proyecto.

Compartir es clave. Te animo a compartir tus experiencias y consejos en los comentarios, gracias por leerme!

Usando cache en Springboot

JaviCoronas — Wed, 27 Jul 2022 12:51:00 +0000

Introducción

Para ponernos en contexto, a veces en un proyecto necesitamos realizar una serie de llamadas hacia nuestro backend de manera muy recurrente. Además de ello, esta llamada apenas tiene cambios a nivel de base de datos. Es decir, realizamos la llamada y consultamos a la base de datos o a un servicio externo prácticamente lo mismo siempre y por consiguiente recibimos la respuesta una y otra vez.

Con este contexto, entra en juego el uso de la cache en nuestro servicio, lo que facilita y ahorra de llamadas innecesarias, ganando en rendimiento de manera muy significativa. Por ejemplo, necesitamos el listado de provincias del país. Sabemos que este listado no va a cambiar pero tampoco queremos ir a nuestra base de datos a pedir cada vez por ellos una vez llamemos a nuestro servicio.

Por ello, el uso de la cache es un mecanismo para mejorar el rendimiento de nuestro servicio con el uso de la memoria temporal que tiene interna nuestro servicio desplegado.

Cache en Springboot

El uso básico de cache en Springboot se puede implementar de manera muy sencilla. En este artículo voy a describir un uso muy sencillo, viendo ya en algo básico como esto un aumento del rendimiento de nuestra aplicación.

Uso de la Cache

Para poder empezar a implementar nuestra cache, la anotación que vamos a emplear es @Cacheable, y es la que utilizamos en Spring para marcar las funciones que queremos cachear en memoria. Esto hará que la primera vez invocadas guarden el resultado en memoria y las siguientes veces hagan uso de esa misma memoria.

Normalmente esto lo desarrollaremos en la capa de Servicio aunque podríamos implementarlo en la capa de repositorio igualmente.

    @Cacheable("books")
    override fun getBooks(): List<Book>? {
         println("Service layer. getBooks")
         Thread.sleep(2000L)
         return repo.findAll()
    }

El nombre que asignamos es importante, ya que es la clave con la que guardamos el resultado en memoria.

De igual manera podríamos cachear la consulta a un libro específico de la siguiente manera:

    @Cacheable("book", key = "#id")
    override fun getBookById(id: Long): Book? {
        println("Service layer. getBookById")
        Thread.sleep(2000L)
        return repo.findById(id).orElseGet(null)
    }

En ambos ejemplos he puesto un sleep de 2 segundos para apreciar los resultados que luego muestro, ya que en un servicio tan básico, la diferencia entre cachear y no cachear seria de poquitos ms.

Una vez marcados nuestros métodos con @Cacheable, sólo habría que marcar nuestra aplicación con @EnableCaching para indicar a Spring que vamos a hacer uso del cache en la aplicación:

@SpringBootApplication
@EnableCaching
class CacheServiceApplication : CommandLineRunner {
      ......
}

Y esto es todo... nada más! Así de sencillo quedaría nuestra cache implementada en nuestro servicio. Vamos con las pruebas.

Realizamos nuestra primera llamada al listado de libros:

Vemos como la respuesta la recibimos 2 segundos despues, pero si volvemos a hacerla...magia!

Vemos que ha hecho uso de la cache y la respuesta nos llega en un volado.

Lo mismo sucede con la llamada a getBookById:

Y en la segunda llamada:

Conclusiones

El potencial de esta herramienta es muy grande y hay muchas opciones de configuración con integraciones más complejas, pero ya veis con que poquitas líneas de código Spring nos permite crear una cache en nuestra aplicación que realmente funciona muy bien y con la que podremos ganar mucho rendimiento, aunque hay que saber explotarla y no abusar tampoco ;).

El código del proyecto podéis encontrarlo aquí

Hasta la próxima!