Buenas prácticas para crear una Pull Request

Las Pull Requests tienen un papel crucial en la rutina diaria de los desarrolladores. A menudo, suelen enfocarse en la creación de código, pero a veces pasan por alto otras partes del proceso de desarrollo que, si se mejoran, podrían marcar una gran diferencia en la eficiencia y productividad de todo el equipo. En este post, analizamos buenas prácticas para crear Pull Request efectivas. ¡Vamos allá!

¿Qué es una Pull Request?

Una Pull Resquest o una solicitud de extracción es una herramienta de comunicación en el desarrollo. Los desarrolladores utilizan las solicitudes de extracción para explicar su trabajo al resto del equipo (gerentes, scrum masters, testers, etc.).

Una solicitud de extracción ofrece una vía para la comunicación abierta, instando a los miembros del equipo a hablar sobre cambios de código, analizarlos y hacer recomendaciones para mejoras.

Cuando los desarrolladores crean una solicitud de extracción, están preparando el terreno para la colaboración con testers y otros desarrolladores, facilitando a quienes revisan el código, entenderlo e identificar y corregir cualquier problema antes de fusionar el código en producción. Debido a esto, seguir las mejores prácticas de las solicitudes de extracción puede ayudar a mantener la calidad del código.

¿Cómo funcionan las Pull Resquest?

Antes de solicitar una Pull Request, el desarrollador crea un fork en el repositorio principal. Un fork es un nuevo repositorio que tiene la misma visibilidad y código que el repositorio original. Los forks permiten a los desarrolladores iterar en cambios de código antes de agregarlos al repositorio original. Este repositorio creado se clona en la máquina local del desarrollador. 

Una vez que haya completado y probado los cambios en el código, puede enviar los cambios al «fork» que creó. Ahora, se puede realizar una solicitud de extracción. Una vez que se realiza la solicitud de extracción, se avisa al equipo sobre los nuevos cambios de código para que puedan ser revisados. El encargado generalmente es un miembro del equipo de DevOps que se encarga de gestionar el repositorio. Esta persona aprueba los cambios de código y decide qué solicitudes de fusión están listas para fusionarse con el repositorio principal y, finalmente, llevarse a producción. Aunque el encargado del repositorio es quien toma la decisión final sobre los cambios de código, generalmente no es quien revisa primero la solicitud de extracción. Por lo general, una solicitud de extracción primero pasa por testers u otros desarrolladores.

Las solicitudes de extracción también pueden utilizarse como una solicitud de ayuda. Si un desarrollador tiene problemas y no puede encontrar una solución adecuada, puede utilizar una solicitud de extracción para obtener comentarios constructivos de otros miembros del equipo.

Para garantizar que todo este proceso se lleve a cabo sin problemas, los desarrolladores deben invertir tiempo redactando la solicitud de extracción antes de enviarla. El proceso de redacción de una solicitud de extracción incluye darle un título a la solicitud de extracción y describir los cambios de código incluidos en la misma.

Los equipos suelen crear plantillas de solicitudes de extracción para ayudar en este proceso. Un resumen típico de una Pull Request incluye lo siguiente:

• Un resumen de las actualizaciones realizadas en el código para explicar qué estaba tratando de lograr el desarrollador con su trabajo (corrección de errores, nueva función, etc.).
• Casos de prueba unitarios que documentan si el nuevo código ha sido probado adecuadamente en todos los navegadores o dispositivos necesarios.

El proceso de solicitud de extracción protege al repositorio principal de código insatisfactorio, fomenta la comunicación abierta y la colaboración a lo largo del ciclo de desarrollo y documenta el trabajo de sus desarrolladores.

Mejores prácticas para crear una Pull Request

En la mayoría de los equipos de desarrollo, las solicitudes de extracción son una parte inevitable del proceso de desarrollo. Si se desea que el código se integre eventualmente en el producto, primero se debe enviar una solicitud de extracción.

Sin embargo, la existencia de solicitudes de extracción por sí sola no garantiza buenos resultados. Aquí mostramos algunas iniciativas a seguir para comenzar a producir solicitudes de extracción que impacten positivamente en el proceso de desarrollo.

Revisión independiente

Aunque el propósito de una solicitud de extracción es que alguien más revise el trabajo, se debe solicitar al equipo a tomarse el tiempo de revisar el código ellos mismos antes de crear la solicitud de extracción.

Revisar el código antes de enviar una solicitud de extracción para detectar errores comunes y facilitar el trabajo de los testers o encargados del repositorio. Si se observa algo en el código que podría ser confuso o interpretado de diferentes maneras, se pueden dejar comentarios en línea para explicar las elecciones y cambios de código.

Crear Pull Request en Borrador

La mayoría de las plataformas populares de alojamiento de código, como GitHub y GitLab, permiten crear borradores de las solicitudes de extracción antes de realizar las solicitudes reales. Aprovechar esto y crear borradores de tus solicitudes de extracción incluso antes de terminar todos tus cambios de código para obtener comentarios tempranos sobre tu código.

Las solicitudes de extracción en borrador son una vía fácil para recopilar aportes y sugerencias del equipo, incluso antes de estar listo para realizar cambios.

Pull Request breves

Hay muchas ventajas en mantener las Pull Request breves. Mantener las solicitudes de extracción cortas permite que, durante la revisión, se pueda prestar atención y analizar los cambios más rápidamente.

Cuanto más larga sea la solicitud de extracción, más tiempo llevará revisarla y dar retroalimentación. Las solicitudes de extracción más pequeñas son un pilar de las prácticas de desarrollo de software ágil. También fomentar estrategias de desarrollo de shift-left, que busquen aumentar la velocidad del proceso de desarrollo al mismo tiempo que garantizar la seguridad del código mediante pruebas tempranas y frecuentes en el ciclo de vida del desarrollo.

Sin embargo, escribir solicitudes de extracción cortas es más fácil decirlo que hacerlo. Las solicitudes de extracción pueden aumentar rápidamente en longitud después de escribir pruebas para ellas. Se necesita práctica y un plan para mantenerlas concisas pero lo suficientemente detalladas para proporcionar contexto.

Algunos equipos crean solicitudes de extracción más cortas, dividiéndolas en unidades como la capa de la base de datos o el publicador de eventos. Experimentar con varios métodos para mantener las solicitudes de extracción cortas y adoptar el sistema que funcione mejor para el equipo.

Crear títulos y descripciones claras

Ofrecer la mayor información sobre el contexto posible al redactar mensajes de confirmación para las solicitudes de extracción para facilitar la comprensión y revisión del código. Si el revisor no sabe qué problema estás intentando resolver con los cambios de código, no sabrá si se ha tenido éxito en abordarlo y resolverlo.

La forma más fácil de proporcionar el contexto necesario para las solicitudes de extracción es escribir un título y una descripción claras para tu mensaje de confirmación. Un buen título de solicitud de extracción indica claramente lo que se ha cambiado, por ejemplo, «Se añadió un caso de prueba para X».

Incluir elementos visuales, como capturas de pantalla, videos y GIFs, para mejorar la descripción, especialmente al realizar cambios en el front-end. Cuando el revisor puede ver los cambios, es más fácil entender y validar los cambios realizados en la interfaz de usuario del producto y en la experiencia general.

Una buena descripción de la solicitud de extracción explica qué cambios se realizaron, expone el propósito de la solicitud de extracción y explica claramente cómo la solicitud de extracción logra sus objetivos. También debe incluir el plan de pruebas para la solicitud de extracción.

La estrategia de pruebas es importante, ya que ayuda a los revisores saber cómo ejecutar las pruebas unitarias, qué áreas de código se probaron y qué pruebas se realizaron. También es importante, incluir los resultados de prueba, tanto exitosos como fallidos. Proporcionar transparencia en las pruebas permite al revisor de la solicitud de extracción realizar sus pruebas y verificaciones de manera más efectiva.

Conclusión

La implementación de estas buenas prácticas para crear una Pull Request no solo acelera el desarrollo y mejora la calidad del código, sino que también fomenta una cultura de comunicación abierta y colaboración, creando un entorno propicio para el crecimiento y la productividad del equipo de desarrollo.

Descubre más contenidos sobre desarrollo ágil en nuestro canal de YouTube.