Los programadores de la vieja guardia recordamos con nostalgia aquellos tiempos en los que uno simplemente cambiaba algo, lo subía a su repositorio y de ahí se iba directamente a producción… bueno, siempre que ello ocurriera sin incidentes.

Conforme los equipos crecían y cada vez se erradicaba el concepto del programador solitario, se hacía evidente que se necesitaba un mecanismo de comprobación para evitar que cuando un programador subiera algo, ese algo no rompiera el código o que introdujera algún problema de seguridad en producción. Fué entonces que el concepto de “pull request” comenzó a tomar fuerza.

Pero, ¿qué es un pull request? El concepto surge particularmente en el sistema de control de versiones git, y de hecho algunos como Mercurial han tratado de implementar algo similar. La idea central es: cuando un developer está por integrar cambios desde una rama hacia development o master, antes de que sus cambios se integren, uno o varios desarrolladores del equipo puedan revisar dichos cambios, proponer ajustes y aceptar o rechazar la integración de los mismos, esto tiene varias ventajas:

  1. El código que se integra es revisado por más de una persona y por tanto hay mayor confianza en que el código ha sido validado por el equipo y que no contiene errores o problemas de implementación evidentes.
  2. Se pueden sugerir cambios al desarrollador para mejorar el código o corregir problemas. Los comentarios sirven de evidencia de revisión y permiten una discusión abierta de la implementación, dejando lugar a menos situaciones de código oscuro o incomprensible.
  3. Reduce la posibilidad de introducir bugs o malas prácticas de desarrollo.
  4. Permite una mayor interacción entre los equipos para discutir las mejores aproximaciones a la resolución de problemas, y se obtienen consensos acerca de cómo debe implementarse una solución (no sólo tomando en cuenta la visión o experiencia del desarrollador a cargo de implementar la solución).

Al parecer, todo parece maravilloso, no?. Pues si, parece. Pero es verdad que también dentro de este proceso existen problemas que no son tan evidentes al principio pero pueden suponer más problemas que soluciones.

  1. El ego de las personas del equipo (en especial de los Tech Leads o Project Managers) puede derivar en convertir una buena herramienta y práctica de programación en una pesadilla proto-fascista donde sólo se plasma la visión y ego de una persona y no priva la mejora continua o las mejores prácticas.
  2. Si los pull requests pueden quedar atorados durante horas o días completos, hace más lento el desarrollo y provoca problemas de integración a veces difíciles de solucionar. Se necesita por tanto que los approvers sean ágiles y tengan un equilibrio entre revisar todo con cepillo de dientes y dejar que se cuelen errores evidentes por no leer el código.
  3. Si no hay un estándar al momento de hacer comentarios o recomendaciones puede ocurrir que dichos comentarios no sean apropiados, que se generen conflictos por malas interpretaciones o directamente una mala práctica de comunicación (insultos, sarcasmos, culpas). Se debe por tanto tener cuidado en cómo se expresan las correcciones y en qué terminos.

Recientemente un usuario en twitter comentaba lo siguiente:

Entre otras cosas, se quejaba de precisamente todos estos problemas que se generan cuando una buena práctica de programación se implementa de manera equivocada y se producen incentivos perversos.

Mi contestación fue la siguiente:

Y si. Muchas veces le echamos la culpa a las herramientas, pero en realidad el problema son las personas. Si en un equipo de desarrollo no existe confianza en el trabajo de los demás y no se asume que “shit would happen” (es decir, los errores siempre van a existir), entonces se usan estas herramientas para repartir culpas y no para corregir procesos.

Es necesario entender que el pull request debe ser “blameless” (sin culpar) y que se debe asumir que la idea es siempre mejorar a un punto en que los cambios sean lo suficientemente aceptables y no perfectos. Y que tampoco deben reflejar una visión única o autoritaria para resolver un problema.

La gran mayoría de los conflictos en los pull requests tienen que ver con:

  1. Malas habilidades de comunicación
  2. Egos inflados
  3. Tratar de echar la culpa fuera de nosotros
  4. Falta de entendimiento y de metas de equipo

Todo esto son habilidades personales, no técnicas. Los pull requests ayudan a lo técnico, pero estos puntos los debe arreglar un Project Manager y/o un Tech Lead.