Chemaclass - code-review

Ship, Show, Ask

2025-04-12T00:00:00+00:00

En equipos que se mueven rápido, una de las mayores tensiones que enfrentamos es esta: ¿Cómo seguimos entregando sin comprometer la calidad o la colaboración?

El enfoque tradicional de pull requests a menudo ralentiza las cosas. Esperamos horas, o días, por aprobaciones, incluso para cambios triviales. Pero la alternativa, mergear directamente, puede sentirse imprudente o invisible para el resto del equipo.

Ahí es donde entra la estrategia Ship-Show-Ask. Originalmente descrita por Rouan Wilsenach, este modelo ofrece una forma más flexible y reflexiva de manejar cambios de código. No es solo una estrategia de branching, es un cambio en cómo los equipos colaboran, confían y toman propiedad.

¿Qué es Ship, Show, Ask? #

Es un modelo que clasifica los cambios basándose en cuánta revisión requieren:

Ship: Mergear directamente a main (sin PR)
Show: Abrir un pull request, pero mergearlo inmediatamente
Ask: Abrir un pull request y esperar revisión

La idea clave es usar Ask como el default para la mayoría del trabajo, recurrir a Show cuando el contexto lo hace seguro, y evitar Ship (o reservarlo para casos extremadamente triviales, si se usa).

Por qué prefiero Ask y Show #

Trata cada cambio, incluso los pequeños, como algo que vale la pena compartir. Siempre creo una rama y abro un PR. Proporciona visibilidad, construye un historial compartido, y crea un espacio para opiniones opcionales o asíncronas. Es trabajar con la puerta del garaje abierta, aplicado al código.

Pero no todos los PRs necesitan seguir el mismo proceso de revisión.

Por defecto uso Ask #

Prefiero esperar una revisión de un compañero cuando:

El cambio involucra lógica arriesgada o compleja
Podría impactar a otros desarrolladores o equipos
Introduce decisiones arquitectónicas o estructurales que no se han acordado aún
Se beneficia de input compartido o un segundo par de ojos

Dicho esto, Ask no significa sobre-ingeniar el proceso. A menudo, un revisor reflexivo es suficiente, especialmente si está familiarizado con el dominio. Si el cambio toca un área específica, pediré la opinión de la persona que posee (o mejor entiende) esa parte del código. No necesita involucrar a todos.

En equipos pequeños, requerir dos aprobaciones en cada PR puede convertirse rápidamente en un cuello de botella y ralentizar la entrega de valor. El objetivo es alineamiento y calidad, no ceremonia por sí misma.

Uso Show para cambios seguros y de bajo impacto #

Podría mergear inmediatamente cuando:

Practico pair programming (la revisión ya ocurrió en vivo)
Corrijo erratas o enlaces rotos
Actualizo documentación o changelogs
Refactorizo dentro de un módulo que poseo
Añado tests para comportamiento existente
Hago ajustes no funcionales (formato, logs, comentarios)
Aplico ajustes de UI o estilo sin cambio de lógica

El principio clave: Show es opcional, nunca obligatorio. Elijo Show solo si el cambio es de bajo riesgo y encaja con las expectativas del equipo. Cuando uso Show, me hago responsable del resultado. La responsabilidad es mía.

Por qué este enfoque funciona para mí #

Este modelo me ayuda a:

Entregar más rápido sin comprometer la calidad
Trabajar con mayor autonomía y propiedad
Evitar cuellos de botella, especialmente en equipos pequeños o async
Fomentar una mentalidad de confianza, responsabilidad y toma de decisiones reflexiva

Cambia el objetivo de obtener aprobación a compartir intención y ser dueño del resultado.

¿Qué hace un buen “Show”? #

Un PR Show podría ser la elección correcta cuando:

El cambio es trivial y dentro de mi área de responsabilidad
Nadie está disponible para revisar, y esperar bloquearía el progreso
El PR incluye contexto y razonamiento claro
Estoy abierto a comentarios post-merge
Estoy listo para hacer ajustes de seguimiento si es necesario

Consejos para que funcione #

Algunos consejos prácticos de la experiencia:

Clarifica las expectativas del equipo sobre cuándo usar Show vs Ask
Siempre proporciona contexto en tu PR, incluso si mergeas inmediatamente
Escribe tests para cualquier lógica o comportamiento nuevo
Da la bienvenida a los comentarios post-merge, la revisión no termina en el merge
Reflexiona regularmente como equipo y ajusta el enfoque según sea necesario

Ship, Show, Ask es más que higiene de branching. Construye una cultura de claridad, responsabilidad y confianza, donde los desarrolladores se mueven rápido sin dejar de ser reflexivos.

Si estás cansado de colas lentas de PR y aprobaciones sobre-ingeniadas, pruébalo en tu próximo cambio. ¿Quieres profundizar? Lee el post original de Rouan Wilsenach.

Ajusta la revisión al riesgo. Sé dueño de lo que mergeas.

Pull Requests vs Pair Programming

2021-04-01T00:00:00+00:00

Hablemos de los beneficios de los Pull Requests y el Pair Programming, y mis reflexiones sobre estos después de algunos años de experiencia con ellos.

Pull Requests #

Un Pull Request (PR) es una forma de mostrar tus cambios de código para que se comparen fácilmente con el código existente. Es parte de un flujo de trabajo que ayuda a compartir conocimiento sobre los cambios que se hacen en el sistema.

Un Pull Request es el momento donde pides a tus compañeros que revisen y examinen tus cambios de código.

Normalmente, también se usa:

Para discusiones sobre estilo de código.
Para detectar bugs potenciales.
Para discusiones de arquitectura o diseño una vez que la solución está hecha.

Los Pull Requests no son la mejor herramienta para todo #

El problema es que los PRs suelen estar listos cuando la funcionalidad o bug ya está terminado, en la última etapa del desarrollo. Un PR es una “propuesta de cambio ya hecha para fusionar en el sistema actual”.

El concepto de “Draft PR” existe para indicar que el PR aún no está listo para fusionar, pero ese es otro tema.

Los Pull Requests son una de las mejores herramientas para compartir conocimiento sobre cambios en el sistema, pero a veces se usan mal:

Discusiones sobre estilo de código. El estilo no debería discutirse en un PR. Ya debería haber un CI ejecutando un linter. Si quieres cambiar algo, proponlo en el linter, no en un PR aleatorio.
Detectar bugs. Los bugs y comportamiento esperado deberían cubrirse con tests automatizados. El desarrollador es el primer responsable.
Discusiones de arquitectura o diseño. Cuando una solución está desarrollada y lista para revisión, es difícil “deshacerla” y reescribirla. “¿Por qué lo harías? Ya está hecho y funciona.”

Tener a alguien extra revisando decisiones de diseño puede ayudar, pero podríamos haber resuelto posibles desacuerdos antes.

¿Cuál debería ser el propósito de un Pull Request? #

Compartir conocimiento sobre los cambios propuestos con el equipo.
Asegurar que el equipo está alineado con los múltiples cambios que se envían cada día. Sí, puede incluir verificar el diseño, pero… ¿y si ya es demasiado tarde?

Pair Programming #

El “Pair Programming” puede entenderse de varias formas: pair thinking, roles conductor-navegador, live coding… En realidad es más sencillo de lo que parece:

Miras y ayudas a la otra persona a escribir código, o
Escribes mientras tienes otro par de ojos mirándote y ayudándote.

El Pair Programming ayuda al equipo a trabajar juntos.

El pair programming es trabajar con un cerebro extra y otro par de ojos. La clave es construir un contexto donde ambos compartan el mismo objetivo para encontrar la mejor solución posible, aprendiendo el uno del otro. No se trata de dar con la mejor solución desde el principio. Se trata de hacerlo funcionar, compartir ideas y mejorar juntos. Luego ya refactorizas y limpias el código.

El Pair Programming es una revisión de código continua #

Los Pull Requests son una forma asíncrona de compartir cambios de código, mientras que el Pair Programming es totalmente síncrono porque sucede al mismo tiempo.

Los Pull Requests y el Pair Programming no son excluyentes, pueden coexistir. Son herramientas, y hay que elegirlas con criterio según nuestros objetivos.

El miedo más común que he visto al animar a hacer Pair Programming es la timidez. A algunas personas no les gusta tener ojos encima mientras programan:

Miedo a no saber qué programar o por dónde empezar.
Miedo a que otros se rían de sus soluciones.
Miedo a no tener éxito en público.
Miedo a no poder desarrollar la solución esperada por múltiples razones: malentender la tarea o falta de conocimiento.
Miedo a cambiar de opinión frente a otros.
Miedo a discutir y tomar decisiones en voz alta.
Miedo a estar en desacuerdo con otros.

Después de varios años de experiencia en este tema #

El patrón que rechaza el Pair Programming es básicamente el miedo a salir de tu zona de confort. Y viene de no entender qué es realmente el Pair Programming.

No se trata de presumir ni de ser juzgado, sino de ser transparente (mostrar tus habilidades tal como son) y mejorar como equipo.

Programar es un proceso iterativo que requiere refactorizar continuamente nuestra forma de pensar. Programar con otra persona (con otra forma de pensar) ayuda al equipo a sacar lo mejor de cada uno y a descartar malos hábitos.

El Pair Programming no tiene que usarse siempre ni para todo. Es una herramienta flexible: puedes elegir cómo, cuándo y por qué.

Una regla personal: antes de empezar tareas que tocan múltiples módulos o reglas de negocio complejas, haz un Pair Thinking rápido con un colega más experimentado en ese área.

Todo depende de un contexto y personas particulares: los desarrolladores, las parejas, las tareas, el estado de ánimo.

¿Todavía incómodo con el Pair Programming? #

Si aún te sientes incómodo con alguien a tu lado mientras programas, quizás no estés contento con tu propio código o con el proceso que sigues. Mi forma favorita de trabajar esto es practicar por mi cuenta y mejorar mis habilidades como desarrollador.

Crea y juega con tus propios proyectos personales.
Trabaja en katas de código por tu cuenta y con otros.

La práctica hace al maestro.

Mantén las pull requests, añade pair programming #

No me malinterpretes, los Pull Requests son geniales. Sigue haciéndolos.
La colaboración en equipo es esencial. El Pair Programming apunta a esto.
El Pair Programming anima al equipo a trabajar juntos proactivamente.
No tengas miedo de programar mientras tienes ojos a tu alrededor. Haz preguntas cuando algo no esté claro. Pide ayuda cuando no sepas cómo resolver algo.

Está totalmente bien no saber todo. Lo más importante es saber cómo trabajar juntos.

Compartiendo tus Parches de Git

2020-12-01T00:00:00+00:00

Descubre otra forma de compartir sugerencias con tu equipo de desarrollo.

Imagina esta situación #

Estás revisando un Pull Request (PR), y ves algunas mejoras menores o sugerencias que te gustaría compartir con el autor. Podrías escribir algunos comentarios, y normalmente, eso sería suficiente.

Imagina que para transmitir tu “idea completa” necesitarías cambiar algunos archivos porque simplemente comunicar la imagen completa acabará en un comentario enorme que podría no ser tan claro como podría ser.

¿Qué posibilidades hay aparte de solo comentarios en un PR? #

Bueno, hay múltiples opciones. La clave es ser consciente de ellas y usarlas sabiamente dependiendo de la prioridad de la tarea y los cambios en sí:

Como ya se mencionó, escribir un comentario como retroalimentación es una buena idea por defecto, pero no la única.
Siempre podemos hacer algo de pair-thinking, hablar en cualquier momento. La comunicación siempre es buena para aclarar la posible incertidumbre.
Compartir tus parches de git es otra buena opción.

¡Git diff al rescate! #

¿Y si tú (como revisor) pudieras compartir tu idea sin ningún commit o comentario en el PR, pero compartiendo tus cambios directamente con el autor?

Bueno, eso es realmente posible y muy fácil. Como ya sabes, el comando git diff te da las diferencias entre dos ramas cualesquiera.

git diff origin develop > ../my-origin-develop.patch

Lo que estamos haciendo aquí es redirigir la salida del comando diff a un archivo (también conocido como: parche), para poder compartir esa salida con cualquier otro compañero de equipo.

¿Y ahora qué? #

Bueno, teniendo ese archivo de parche, es bastante fácil aplicar esos cambios en tu máquina local sin hacer ningún commit:

git apply ../my-origin-develop.patch

Aplicar este parche simplemente cambiará tu sistema local de la misma manera que se creó el parche.

“Cómo hacerlo” por pasos #

Dividamos las responsabilidades en dos: el creador del parche y su usuario:

El creador del parche: la persona que creará el parche #

# Cambia a esa rama
$ ~/myProject git:(the-branch) ➜ git pull origin the-branch
# Haz tus sugerencias y cambios en la rama objetivo
# Genera el archivo de parche usando el comando diff
$ ~/myProject git:(the-branch) ➜ git diff > ../your-diff.patch
# Comparte el archivo de parche con el autor del PR

El usuario del parche: la persona que verá el parche #

# Asegúrate de estar en esa rama
$ ~/myProject git:(the-branch) ➜ git pull origin the-branch
# Aplica el archivo de parche
$ ~/myProject git:(the-branch) ➜ git apply ../your-diff.patch

Referencias #

Documentación oficial de “git apply”