Los Pull Requests (PRs) son una herramienta indispensable al trabajar en un proyecto de software.
Si no lo estas usando solo estas incrementando las probabilidades de morir de tu proyecto. ¿Por qué?
Porque los PRs le dan al equipo herramientas adicionales para asegurarse de que los nuevos cambios al código que se integren a un proyecto sean funcionales y no rompan otros módulos de la aplicación.
GitHub (y otros sistemas de repositorios) logran esto permitiendo que cada integrante del equipo pueda revisar los cambios que un miembro quiera integrar. A su vez estos sistemas permiten que se dejen comentarios y/o correcciones asociados a cualquiera de los cambios.
En práctica, estas revisiones las puede hacer cualquier miembro del equipo pero evidentemente es mejor que las personas con mayor conocimiento del proyecto estén involucradas. ¿Es obvio no? Una persona con mayor dominio del tema podrá hacer una revisión de mayor calidad y transmitir su conocimiento a los demás con mayor facilidad.
Dicho esto…usar PRs solo porque si, tampoco es la solucion.
Si no se establecen reglas y buenas prácticas al usarlos, no solo estarás desaprovechando su gran potencial de eficiencia si no que en el peor de los casos hasta podrías estar alentando la productividad del equipo de desarrollo…
¿Pero que son esas cosas, que pueden meterte al pie cuando empiezas a utilizar PRs?
No hay un estándar de descripción para los Pull Requests
Piensa un poco en la logística de un PR. Un desarrollador quiere subir sus cambios a una rama compartida del repositorio. Por ende crea un PR con sus cambios y espera a que el Technical Lead o algún otro integrante del equipo se lo revise.
¿Acaso todos los demás desarrolladores ya saben exactamente que cambios hizo y porque los hizo? Por supuesto que no. Cada integrante tiene sus propias tareas asignadas y esas son sus prioridades (Como debe de ser).
Entonces quien quiera revisar su PR necesita entrar y leer la descripción. Pero si dejamos que cada integrante ponga la descripción como quiera, dejamos al azar el que tan útil pueda ser o no esa descripción. Si la descripción esta bien hecha pues bueno no hay problema. Pero si no, ¿cuáles es la solución? Contactar al desarrollador que abrió el PR claro.
Esto es una pérdida de tiempo, para ambas partes y es fácilmente solucionable definiendo un estándar para todo el equipo en el que se creen los Pull Requests con un formato predefinido para sus descripciones.
Personalmente me gusta una descripción que siga un formato similar a este:
- Tipo de cambio (Bug, feature, refactor, etc)
- Link al Ticket asignado (Jira, Trello, etc)
- Descripcion del cambio
- Pasos para probar la funcionalidad correctamente. Dependiendo del cambio pueden ser:
- Pasos para navegar a las pantallas donde visualizar el cambio
- Pasos para replicar el caso de uso
- Comandos de tests a ejecutar
No se toman en cuenta los PRs en la carga de trabajo
Revisar un PR no es cualquier cosa, siempre va a tomar algo de tiempo. Una buena revisión puede tomar desde 15 minutos hasta un par de horas. A eso súmale que ese tiempo es por PR. Entonces el tiempo se multiplica entre más seccionado este el trabajo. ¿Cuántos tickets tiene asignado tu equipo de desarrollo? ¿Cuántos integrantes son?
Un equipo de 5 con 2 tareas asignadas cada 1 creará 10 Pull Requests. Si nos va bien, nos tomará 15 minutos cada uno y eso será un total de 2 horas y media para revisarlos. Eso es un poco más de 1/4 parte de un día laboral. Ahora si nos vamos al otro extremo de 2 horas por PR ¿Qué pasará? 10 PRs equivalen en este caso a un total de 20 horas…es decir 2 días y medio.
Las consecuencias de sobrecargar a tu equipo de trabajo son evidentes. Se empiezan a descuidar cosas y a cometer errores.. Y en el caso específico de los PRs lo que sufrirá será la calidad de la revisión.
¿Y para que demonios estamos haciendo Pull Requests si no se están revisando como se debe?
No tiene sentido.
Los reviews de los PRs se hacen entre todo el equipo de desarrollo
El que todos los integrantes del equipo se revisen entre sí en teoría suena bien.
“Esto ayuda al trabajo en equipo y aparte ayuda a que los desarrolladores se familiaricen mas rápido con toda la base de código.” – Dicen los que abogan por esta práctica.
¡Pero no! Yo nunca he visto que funcione y te voy a contar que es lo que realmente pasa…
Imagina que estás en un periodo del desarrollo en el que se esta exigiendo que se completen demasiadas tareas, más de las que el equipo puede manejar (un escenario que siempre se da en cualquier equipo tarde o temprano).
Conforme los integrantes van completando sus tareas van subiendo su código y claro …crean sus Pull Requests pidiendo revisión.
Pero…la prioridad de cada desarrollador debe ser completar las tareas que se le asignaron. Nadie suele felicitar a un integrante que no termino su tarea aunque haya sido por ayudar los demás y los desarrolladores están conscientes de esto.
Esta situación en esencia provoca 2 problemas:
- Reviews que se dejan para el final
- Reviews hechas con prisa
Cómo te podrás imaginar ambos traen a su vez otros problemas que se llevan consigo al resto del equipo.
Si las reviews de los PRs se dejan para el final, los desarrolladores se queda con menos tiempo para atender las observaciones y correcciones a su código. Si alguien tenía otras tareas que dependían de esa review peor aún, ya que permanecerá bloqueado y no podrá avanzar hasta que le acepten su PR.
Como el desarrollador esta consciente de estos problemas, tendrá que buscar a cada miembro del equipo para que lo ayude. Y eso es extremadamente ineficiente porque ahora esta distrayendo a mas de 1 miembro del equipo para que le revisen su PR.
Por otra parte los desarrolladores que hagan las reviews también estarán ocupados. Realmente no ignoran las revisiones con mala intención, sino porque tiene claro que lo primero es acabar su propia tarea. Esto mismo los puede llevar a hacer reviews con mas premura y presión de lo habitual. Lo cual a su vez aumenta las probabilidades de omitir errores en la revisión.
Yo te preguntó. ¿Cuál es el punto de un proceso de Pull Requests que no sirve para asegurarse de la calidad del código y que decrementa la efectividad del equipo?
No hay pruebas automatizadas
El no tener pruebas representa un problema mucho más grande que los PRs. Ellos son sólo unas de sus muchas víctimas.
Pero centrándose en el tema… cuando hablamos de Pull Requests debemos de estar pensando en de revisiones de manera eficiente. Si no tienes pruebas automatizadas básicamente le estas dejando a los que revisan el PR la tarea de correr pruebas de manera manual Y no todas…sino de las que se acuerden.
Ya te imaginarás porque esto no es recomendable. Hacer las revisiones de esta manera toma mas tiempo y es más propenso a errores.
El implementar pruebas automatizadas ahorra muchísimo tiempo y da mayor seguridad a los desarrolladores de que los cambios que están implementando funcionan y no afectan a otros módulos.
Incluso si no se pueden implementar todas las pruebas que deberían ser con poner las que correspondan a los casos de uso más importantes o complejos ya ayuda mucho.
No hay duda de que si tienes que elegir entre tener una buena metodología de Pull Requests y no tener ninguna yo te recomiendo la primera. Es un hecho que tomará un tiempo de planeación y corrección adicional pero al final valdrá la pena.
Sin embargo, lo que no es tan obvio es si tienes que elegir entere tener una mala metodología de Pull Requests y no tener ninguna…. entonces por más increíble que parezca, te recomiendo no tenerla.
Si no te tomas el tiempo para asegurarte de que sea buena lo único que aportara al proyecto será la ilusión de que se están haciendo las cosas bien. Pero tras bambalinas estarás echando a la basura bastante del tiempo de cada miembro del equipo.