⚠️ Por qué NO deberías usar PULL REQUESTS para DESARROLLAR ⚠️(GitHub, Bitbucket, GitLab...)

Me atrevo a decir que la gran mayorÍa de personas que están en el mundo del desarrollo del software conocen las PULL REQUEST. De echo, las PR son pieza básica en los workflows como GitFlow y Feature Branching entre otros.

Leyendo todo esto parece que las PR son un "must" para los equipos pero... ¿y si no fuera así?

En este vídeo voy a explicar todos los costes ocultos de las PR y por qué no son la forma más eficiente de trabajar en equipo.

Suscríbete para poder estar al día de todos los videos y no perderte nada :)

► ¡Sígueme!

[txetumaleb]

Buenísimo el video Cristian! está MUY bien explicado, estoy esperando la continuación impaciente!! Enhorabuena!

[josefranciscocrespo]

Grande Cristian! Muy interesante como explicas el coste que tienen las PR.
Like, y suscrito! esperando el próximo video! ;)

[victorded]

Enhorabuena por el video, una explicación muy bien argumentada y sobre la que te sientes identificado cuando lo escuchas. Te animo a que sigas subiendo videos, me da la sensación de que tienes mucho que aportar y compartir. Ánimo, aquí estaremos unos cuantos para verte en los siguientes y ver la segunda parte de este video ;)

[DanielRomanMartinez]

A la espera de saber cual sería la solución ideal :-) Interesante vídeo !

[rodonunez_personal]

Casi dos años en suspenso por el próximo video😆 Buena reflexión =)

[oscarossesa]

Hola Cristian, aunque no estoy de acuerdo con dejar de usar los PRs, cada uno de los puntos que expusiste me pasan al día de hoy en mi trabajo. Evidentemente es un costo, y será decisión de cada equipo/directivo/jefe el sumar o no esta práctica. Me hubiese gustado escuchar una propuesta de mejora...la voy a buscar en tu canal.

Lo que hicimos nosotros:
Acordamos darnos todos los días un desayuno de PRs, por lo que, todos saben que en las mañanas mientras nos tomamos un buen café estamos también revisiando código, acompañado a esto, definimos un tamaño máximo para cada PR (la fórmula: no más de 20 archivos + se consiente con el número de líneas...nos ha costado dar con una métrica), con esto logramos que la revisión no tome tanto tiempo y de pasada, logramos incrementos continuos del producto. Lo otro que realizamos es un onboarding dónde recalcamos que las solicitudes de revisión no pueden llegar a última hora, ya que somos consientes que los revisores además deben estar haciendo sus propias features. Si una de las condiciones no se cumple, el PR es manualmente rechazado al instante. Por último no menos imprtante, existen excepciones, y si son justificadas, puedo detener mi desarrollo para revisar un PR urgente.

[MrLavoe]

Y no hubieron más videos... jejeje muy valida tú opinión, me hubiese gustado más contenido...

[enzodiaz]

Los pr están destinados a desarrolladores secundarios, sin habilidad de administrar el proyecto y sin poder de decisión directo sobre el rumbo.

El trabajo colaborativo no está hecho para ser ágil, sino para tener consenso de todas las partes interesadas.
Antes de plantear una contribución, se debe plantear un conflicto (cosa que aumenta el "feedback loop"). Estos issues tienen un grado de importancia y los managers del proyecto son lo suficientemente inteligentes para priorizar los pull request que solucionen los issues.

Un pr puede estar pendiente a revision y aprobación durante semanas y eso no es algo malo.
El consenso está hecho para garantizar calidad (los 5 puntos que nombraste).
En un equipo de trabajo cerrado, el flujo se agiliza porque todos los programadores son igual de buenos y se pueden dar por hecho muchas cosas con tan solo conocer a tu compañero de oficina.
En un equipo abierto, se requiere un chequeo doble de las propuestas de un desconocido.

[carlesmatamasip]

Se nota que le vas pillando el punto a ésto de YouTube! Mucho mejor éste que el primero, aunque el tema sea incendiario jajaja como dices, un PR es muy típico (e imprescindible) en un proyecto open-source, y de hecho creo que se popularizó con github que esencialmente nació para éstos proyectos. Pero en un equipo privado ya es otra película y no termino de ver la solución ideal. A ver si me la cuentas en el próximo video 😜

[miguelguerrerom]

muy interesante Cristian!.. esperando el siguiente video 🤖

[AbdelioR]

Genial video! se nota que el primer video pasó una code review exhaustiva, este ha mejorado mucho en cuando a edición :D expectante al tercero!

[mcsoleel]

Estoy leyendo el libro "Pro Git" (estoy recién aprendiendo como trabajar colaborativamente), y presentan dos formas de trabajar, por correo o con Pull Request.
Lo de trabajar por correo me parece un desacierto y encontré milagroso el Pull Request, pero con este video me queda claro que hay un costo asociado a automatizar trabajo.

Muchas gracias por la explicación, me encanto.

[ChristianLopezSantos]

Muy interesante. Podría solucionar esto un rol diferente en el equipo de desarrollo? Por ejemplo personas que estén dedicadas a la revisión de código??

[kikesitoskxoxtla]

Lo que dice en el minuto 4:41 sobre las "Inception Pull request" la solución es que siempre se creen las tareas desde la rama base/estable, ya sea main(master), develop o la que se hayan creado pero que se tome como base para crear ramas, esto para evitar esos tiempos de pérdida que tienen un PR, entonces lo ideal es que cuando te aprueben tareas/tickets, etc. es que se haga un _pull_ desde la rama base, en el mejor de los casos se hará un fast-foward, en el peor toca revisar con tu colega de código donde han surgido problemas, pero no creo que sea un impedimento en la mayoría de los casos esperar a que te aprueben un PR para seguir con otra tarea/ticket.

[MauroBonfietti]

Muuuuy interesante video, muy bien explicado. Ya le di like y suscribir :-)

[isaacaymerich]

Mucha razon, a ver si sacas la solucion ;)

[didaquis]

Cristian, me molaría mucho que hicieras un vídeo explicando los 4 patrones de desarrollo que un programador junior debería aprender. Una selección de los 4 más útiles explicados con sus proa y sus contras, indicando que problema tratan de resolver cada uno de ellos.

[hazelhumor]

Lo mejor es la primera PR que haces al llegar a una empresa. De 50 comentarios no bajas.

[mvilac]

Gracias por el vídeo Cristian, sin embargo creo que le estás atribuyendo unos "superpoderes" (que se terminan convirtiendo en problemas) a las PR que no tienen, desde mi punto de vista:
- Si pretendes analizar las posibles soluciones, y elegir la mejor en la PR... lo has hecho al revés. Mejor que el developer elija analice las soluciones y elija una antes de desarrollar, aunque tenga que preguntar a otro.
- Respecto al testear: procura usar test unitarios que se puedan lanzar de forma automática, y si lo que quieres es hacer testing funcional... lo mismo es que estás haciendo tareas de otro rol.
- Tener menos bugs en producción: no creo que sea uno de los principales motivos para hacer PRs, puedes pillar algún gazapo pero será la excepción, para esto está el testing del que hablabamos.
Para mí esa parte colaborativa que tiene la revisión creo que es muy positiva, aunque ralentice un poco la integración de una feature, tanto revisor como revisado suelen aprender algo que se puede hacer mejor.
Estoy de acuerdo en que puede haber proyectos o equipos donde las PR no sean necesarias, pero tampoco afirmar categoricamente que NO debieramos usarlas salvo excepciones.
Saludos.

[qazsero]

No me ha gustado el video, pero no voy a darle dislike, prefiero explicar
Antes que nada llevo 10 minutos y 40 segundos esperando la razón por la que no usar PR's, es decir, la solución alternativa...Vale, no hay, bien. A mi el video se me hace mas bien como un tutorial que explica que son PR's, y si no lo supiera, no hubiese abierto el video.
Los problemas que expones me parecen pasos necesarios, otra persona que no seas tu tiene que revisar tu trabajo, ahora, la manera de la que te organizas en tu oficina para los review la tienen que decidir ustedes según vuestra forma de trabajar. Nosotros por ejemplo ponemos reuniones entre el autor y 2 devs reviewer en los calendarios, interrumpen el trabajo? Igual que cualquier otra reunión como Sprint planning, backlog refinement, release planning, sprint demo, sprint retrospective..Y todas necesarias. A lo que voy, es que las las razones que expones me parece que se pueden aplicar a cualquier reunión, y la solución es una organización que permite tener X cantidad de reuniones por semana en timeslots determinados del calendario que a su vez permite a los desarrolladores reservar ranuras en su calendario solo para programar.
Estoy abierto a cualquier comentario :) si tienes algo en mente en lo que estás en desacuerdo me encantaria escucharlo.