3 Buenas Prácticas para tus Pull Requests
Los Pull Requests o PRs son una de las mejores formas para trabajar en equipos de desarrollo y proponer cambios en el código fuente.
El proceso es muy simple, el dev que quiere hacer cambios en un código crea una rama hija de la rama a modificar, tras hacer un push de los commits con sus cambios, hacer una petición de unir los cambios de la rama hija a la rama padre. Esta petición será aprobada por uno o varios revisores que darán el visto bueno para unir esta rama (merge).
Algunas ventajas de este proceso son:
- Facilita la revisión del código.
- Es una buena forma de ganar experiencia, tanto para el que hace la revisión como para quien recibe críticas o recomendaciones de mejora.
- Reduce la posibilidad de bugs en el código fuente.
- Ayuda a nuevos devs entender cómo se escribe el código y se hacen las cosas (onboarding)
- Acelera la revisión del código.
Sin embargo este proceso como todo, puede llegar a ser un caos si no se manejan las buenas prácticas que veremos a continuación:
1. Tamaño
Uno de los principales problemas al hacer un PR es el tamaño, un estudio de CISCO reveló que revisar de entre 200 a 400 lineas de código toma de entre 60 a 90 minutos, ocasionando que:
- El revisor está bloqueado todo este tiempo.
- Se bloquean otros devs que pueden requerir modificar el mismo código.
Es imposible definir cuántas líneas de código incluir en un PR, ya que dependerá mucho de la tarea, los cambios requeridos y cómo está organizado el equipo. Sin embargo te dejo algunas referencias:
- Divide y vencerás: si notas que la tarea es muy grande, habla con tu equipo o superior para dividirla o realiza diferentes PRs.
- Principio de responsabilidad única: Este principio habla de que una clase o función debe realizar una sola tarea. Esto se puede extrapolar a las tareas que hacemos, cada PR debería tener un fin en específico.
- No más de 200 líneas de código modificadas.
2. Título y descripción
El título es muy importante, ya que da una idea del motivo del PR, es por ello que el título debe ser específico y claro. Algunos equipos cuentan con nomenclaturas definidas para escribir los títulos como una combinación entre el número de ticket en el tracker y el nombre de la tarea.
La Descripción es ese campo que solemos dejar vacío, sin embargo es una extensión del título y da a los revisores más contexto de qué y cómo revisar el PR. Muchas herramientas permiten agregar templates en esta parte, para tener una idea de que debemos introducir en este campo.
Algunas sugerencias son:
- El contexto del PR, por qué se está realizando este cambio.
- Desde donde empezar a revisar el PR y el orden en que seguir.
- Prioridad de la tarea y/o tipo de tarea (Bug, chore, feature)
- Links adicionales ya sea al ticket u otros recursos.
3. Respondiendo a la crítica
Cuando haces un PR, es por que necesita revisión y claramente alguien la hará, por ello:
- No tomes personal cualquier comentario, tómalo como una oportunidad de mejorar y aprender.
- Responde todos los comentarios que se te hacen, no simplemente resuelvas el problema.
- Atento a las preguntas, es común que cuando un revisor realice alguna pregunta, los devs salten al código a cambiarlo. Si es una pregunta es por que se espera una respuesta, no es una solicitud de cambio.
- Si notas que algún comentario es personal o fuera de lugar, no caigas en responder de la misma manera.
- Resuelve las conversaciones . Github y otras herramientas tienen un botón que se llama Resolve Conversations y debe presionar para indicar al revisor que ese punto ya fue trabajado.
4. Extra
- Escribe código legible, con variables y funciones bien declaradas.
- No dejes los logs innecesarios.
- No dejes ningún código comentado a menos que sea muy necesario.
- Se organiza con tu código.
- Cuidado con los Typos o errores de escritura
- En serio, cuídate mucho de la escritura, manejo de mayúsculas o minúsculas, etc., ya sea en documentación o en tu código.
El PR es como la carta de presentación de cualquier desarrollador, es donde muestras tu trabajo y allí se denotará fácilmente el seniority que tienes, además de la experiencia, es por eso que te recomiendo que le pongas mucha atención y seas detallista al momento de hacer un PR.
Referencias:
https://opensource.com/article/18/6/anatomy-perfect-pull-request
