Llevar una mentalidad saludable de revisión de código a su equipo

Una 'revisión de código' es un momento en el proceso de desarrollo en el que usted (como desarrollador) y sus colegas trabajan juntos y buscan errores en una pieza de código reciente antes de que se publique. En ese momento, puede ser el autor del código o uno de los revisores.

Al realizar una revisión de código, es posible que no esté seguro de lo que está buscando. Por otro lado, al enviar una revisión de código, es posible que no sepa qué esperar. Esta falta de empatía y las expectativas equivocadas entre las dos partes pueden desencadenar situaciones desafortunadas y acelerar el proceso hasta que termine en una experiencia desagradable para ambas partes.

En este artículo, compartiré cómo se puede cambiar este resultado cambiando su mentalidad durante una revisión de código:

• Como un equipo
• como autor
• como revisor

trabajando en equipo

Fomentar una cultura de colaboración

Antes de comenzar, es fundamental comprender el valor de por qué es necesario revisar el código. El intercambio de conocimientos y la cohesión del equipo son beneficiosos para todos, sin embargo, si se hace con una mala mentalidad, una revisión de código puede consumir mucho tiempo con resultados desagradables.

La actitud y el comportamiento del equipo deben adoptar el valor de una colaboración sin prejuicios, con el objetivo común de aprender y compartir , independientemente de la experiencia de los demás.

Incluya revisiones de código en sus estimaciones

Una revisión completa del código lleva tiempo. Si se tardó una semana en realizar un cambio, no espere que la revisión del código demore menos de un día. Simplemente no funciona así. No intente acelerar la revisión del código ni lo mire como un cuello de botella.

Las revisiones de código son tan importantes como escribir el código real. Como equipo, recuerde incluir revisiones de código en su flujo de trabajo y establezca expectativas sobre cuánto tiempo puede llevar una revisión de código, para que todos estén sincronizados y confiados en su trabajo.

Ahorre tiempo con pautas y automatización

Una forma efectiva de garantizar contribuciones consistentes es integrar una plantilla de solicitud de extracción en el proyecto. Esto ayudará al autor a enviar un PR saludable con una descripción completa. Una descripción de relaciones públicas debe explicar cuál es el propósito del cambio, la razón detrás de él y cómo reproducirlo. Las capturas de pantalla y los enlaces de referencia (problema de Git, archivo de diseño, etc.) son los toques finales para un envío que se explica por sí mismo.

Hacer todo esto evitará que los primeros comentarios de los revisores soliciten más detalles. Otra forma de hacer que las revisiones de código parezcan menos quisquillosas es usar linters para encontrar problemas de formato y calidad del código antes de que un revisor se involucre. Cada vez que vea un comentario repetitivo durante el proceso de revisión, busque formas de minimizarlo (con mejores pautas o automatización del código).

Quédate como estudiante

Cualquiera puede hacer una revisión del código y todos deben recibir una revisión del código, sin importar el nivel de antigüedad. Reciba cualquier comentario con agradecimiento como una oportunidad para aprender y compartir conocimientos. Considere cualquier comentario como una discusión abierta en lugar de una reacción defensiva. Como dice Ryan Holiday:

“Un aficionado está a la defensiva. El profesional encuentra divertido aprender (e incluso, en ocasiones, aparecer en público); les gusta que los desafíen y los humillen, y se involucran en la educación como un proceso continuo e interminable. (...)”

— Ryan Holiday, El ego es el enemigo

Mantente humilde porque en el momento en que dejas de ser estudiante, tu conocimiento se vuelve frágil.

El arte de seleccionar revisores

En mi opinión, elegir a los revisores es una de las decisiones más importantes para una revisión de código efectiva y saludable como equipo.

Supongamos que su colega está enviando una revisión de código y decide etiquetar a "todos" porque, inconscientemente, es posible que quiera acelerar el proceso, entregar el mejor código posible o asegurarse de que todos sepan sobre el cambio de código. Cada uno de los revisores recibe una notificación, luego abre el enlace PR y ve muchas personas etiquetadas como revisores. El pensamiento de "alguien más lo hará" aparece en sus mentes, lo que lleva a ignorar la revisión del código y cerrar el enlace.

Dado que nadie comenzó la revisión todavía, su colega le recordará a cada uno de los revisores que lo haga, es decir, ejercerá presión sobre ellos. Una vez que los revisores comienzan a hacerlo, el proceso de revisión lleva una eternidad porque todos tienen su propia opinión y es una pesadilla llegar a un acuerdo común. Mientras tanto, quienquiera que haya decidido no revisar el código, recibe miles de millones de notificaciones por correo electrónico con todos los comentarios de revisión, lo que genera ruido en su productividad.

Esto es algo que veo que sucede más de lo que me gustaría: Solicitudes de extracción con un grupo de personas etiquetadas como revisores y que terminan, irónicamente, en una revisión de código no productiva.

Hay algunos flujos efectivos comunes al seleccionar a los revisores: Un posible flujo es elegir a dos o tres colegas que estén familiarizados con el código y pedirles que sean revisores. Otro enfoque, explicado por el equipo de Gitlab, es tener un flujo de revisión encadenado en el que el autor elige a un revisor que elige a otro revisor hasta que al menos dos revisores estén de acuerdo con el código. Independientemente del flujo que elija, evite tener demasiados revisores . Ser capaz de confiar en el juicio del código de sus colegas es la clave para realizar una revisión de código eficaz y saludable.

tener empatía

Detectar piezas de código para mejorar es solo una parte de una revisión de código exitosa. Igual de importante es comunicar esa retroalimentación de una manera saludable mostrando empatía hacia sus colegas.

Antes de escribir un comentario, recuerda ponerte en el lugar de los demás. Es fácil ser malinterpretado al escribir, así que revise sus propias palabras antes de enviarlas. Incluso si una conversación comienza a ser fea, no dejes que te afecte, sé siempre respetuoso. Hablar bien a los demás nunca es una mala decisión.

saber cómo comprometerse

Cuando una discusión no se resuelve rápidamente, llévela a una llamada o chat personal. Analicen juntos si es un tema que vale la pena paralizar la solicitud de cambio actual o si se puede abordar en otra.

Sea flexible pero pragmático y sepa cómo equilibrar la eficiencia (entrega) y la eficacia (calidad). Es un compromiso que se debe hacer como equipo. En estos momentos me gusta pensar en una revisión de código como una iteración en lugar de una solución final. Siempre hay espacio para mejorar en la próxima ronda.

Revisiones de código en persona

Reunir al autor y al revisor en un estilo de programación en pareja puede ser muy efectivo. Personalmente, prefiero este enfoque cuando la revisión del código implica cambios complejos o existe la oportunidad de compartir una gran cantidad de conocimientos. A pesar de que se trata de una revisión de código fuera de línea, es un buen hábito dejar comentarios en línea sobre las discusiones realizadas, especialmente cuando es necesario realizar cambios después de la reunión. Esto también es útil para mantener actualizados a otros revisores en línea.

Aprender de los resultados de la revisión del código

Cuando una revisión de código ha sufrido muchos cambios, tomó demasiado tiempo o ya ha tenido demasiadas discusiones, reúna a su equipo y analice las causas y qué acciones se pueden tomar. Cuando la revisión del código es compleja, dividir una tarea futura en tareas más pequeñas facilita cada revisión del código.

Cuando la brecha de experiencia es grande, adoptar la programación en pareja es una estrategia con resultados increíbles, no solo para compartir conocimientos, sino también para la colaboración y la comunicación fuera de línea. Sea cual sea el resultado, siempre apunte a un equipo sano y dinámico con expectativas claras.

como autor

Una de las principales preocupaciones cuando se trabaja en una revisión de código como autor es minimizar la sorpresa del revisor al leer el código por primera vez. Ese es el primer paso para una revisión de código predecible y fluida. Así es como puedes hacerlo.

Establecer comunicación temprana

Nunca es una mala idea hablar con tus futuros revisores antes de codificar demasiado. Siempre que sea una contribución interna o externa, podrían hacer un refinamiento juntos o un poco de programación en pareja al comienzo del desarrollo para discutir soluciones.

No hay nada de malo en pedir ayuda como primer paso. De hecho, trabajar juntos fuera de la revisión es un primer paso importante para prevenir errores tempranos y garantizar un acuerdo inicial. Al mismo tiempo, sus revisores se enteran de que se realizará una futura revisión del código.

Siga las pautas

Al enviar una solicitud de extracción para su revisión, recuerde agregar una descripción y seguir las pautas. Esto evitará que los revisores dediquen tiempo a comprender el contexto del nuevo código. Incluso si sus revisores ya saben de qué se trata, también puede aprovechar esta oportunidad como una forma de mejorar sus habilidades de escritura y comunicación.

Sea su primer revisor

Ver su propio código en un contexto diferente le permite encontrar cosas que extrañaría en su editor de código. Realice una revisión del código de su propio código antes de preguntar a sus colegas. Tenga una mentalidad de revisor y realmente revise cada línea de código.

Personalmente, me gusta anotar mis propias revisiones de código para guiar mejor a mis revisores. El objetivo aquí es evitar comentarios relacionados con una posible falta de atención y asegurarse de que siguió las pautas de contribución. Trate de enviar una revisión de código tal como le gustaría recibir una.

Se paciente

Después de enviar una revisión del código, no salte directamente a un nuevo mensaje privado pidiéndoles a sus revisores que "echen un vistazo, solo toma unos minutos" e indirectamente anhelando ese emoji de pulgar hacia arriba. Tratar de apresurar a sus colegas para que hagan su trabajo no es una mentalidad saludable. En su lugar, confíe en el flujo de trabajo de sus colegas como ellos confían en usted para enviar una buena revisión de código. Mientras tanto, espera a que te respondan cuando estén disponibles. No mires a tus revisores como un cuello de botella. Recuerda ser paciente porque las cosas difíciles toman tiempo.

ser un oyente

Una vez que se envía una revisión del código, llegarán comentarios, se harán preguntas y se propondrán cambios. La regla de oro aquí es no tomar ningún comentario como un ataque personal. Recuerde que cualquier código puede beneficiarse de una perspectiva externa .

No mires a tus revisores como un enemigo. En cambio, aproveche este momento para dejar de lado su ego, aceptar que comete errores y estar abierto a aprender de sus colegas, para que pueda hacer un mejor trabajo la próxima vez.

como revisor

Planifique con anticipación

Cuando se le pida que sea un revisor, no interrumpa las cosas de inmediato. Ese es un error común que veo todo el tiempo. La revisión del código exige toda su atención y cada vez que cambia de contexto de código, está disminuyendo su productividad al perder tiempo en recalibrar su enfoque. En su lugar, planifique con anticipación asignando franjas horarias de su día para realizar revisiones de código.

Personalmente, prefiero hacer revisiones de código a primera hora de la mañana o después del almuerzo antes de elegir cualquier otra de mis tareas. Eso es lo que funciona mejor para mí porque mi cerebro aún está fresco sin un contexto de código anterior para desconectarme. Además de eso, una vez que termine con la revisión, puedo concentrarme en mis propias tareas, mientras que el autor puede volver a evaluar el código en función de los comentarios.

Ser de apoyo

Cuando una solicitud de extracción no sigue las pautas de contribución, brinde apoyo, especialmente a los recién llegados. Toma ese momento como una oportunidad para guiar al autor a mejorar su contribución. Mientras tanto, trata de entender por qué el autor no siguió las pautas en primer lugar. Tal vez hay margen de mejora que no conocías antes.

Echa un vistazo a la sucursal y ejecútala

Mientras revisa el código, haga que se ejecute en su propia computadora, especialmente cuando se trata de interfaces de usuario. Este hábito lo ayudará a comprender mejor el nuevo código y detectar cosas que podría perderse si solo usara una herramienta de diferenciación predeterminada en el navegador que limita el alcance de su revisión al código modificado (sin tener el contexto completo como en su editor de código) .

Preguntar antes de asumir

Cuando no entienda algo, no tenga miedo de decirlo y hacer preguntas. Cuando pregunte, recuerde leer primero el código circundante y evite hacer suposiciones.

La mayoría de las preguntas encajan en estos dos tipos de categorías:

1. Preguntas de "cómo"
   Cuando no comprenda cómo funciona algo o qué hace, evalúe con el autor si el código es lo suficientemente claro. No confundas el código simple con la ignorancia. Hay una diferencia entre el código que es difícil de leer y el código que no conoce. Esté abierto a aprender y utilizar una nueva característica del idioma, incluso si aún no la conoce en profundidad. Sin embargo, utilícelo solo si simplifica la base de código.
2. Preguntas de “por qué”
   Cuando no comprenda el "por qué", no tenga miedo de sugerir comentar el código, especialmente si se trata de un caso límite o una corrección de errores. El código debe explicarse por sí mismo cuando se trata de explicar lo que hace. Los comentarios son un complemento para explicar el por qué de un determinado enfoque. Explicar el contexto es muy valioso cuando se trata de la mantenibilidad y evitará que alguien elimine un bloque de código que pensó que era inútil. (Personalmente, me gusta comentar el código hasta que me sienta seguro de olvidarlo más tarde).

Crítica constructiva

Una vez que encuentre un fragmento de código que crea que debe mejorarse, recuerde siempre reconocer el esfuerzo del autor por contribuir con el proyecto y expresarse de manera receptiva y transparente.

• Discusiones abiertas.
  Evite formalizar sus comentarios como una orden o acusación como “Debería…” o “Se le olvidó…”. Exprese sus comentarios como una discusión abierta en lugar de una solicitud obligatoria. Recuerda comentar el código, no el autor. Si el comentario no es sobre el código, entonces no debería pertenecer a una revisión de código. Como se dijo antes, sé solidario. Usar una voz pasiva, hablar en plural, expresar preguntas o sugerencias son buenos enfoques para enfatizar la empatía con el autor.
  

En lugar de "Extraer este método de aquí...", prefiera "Este método debe extraerse..." o "¿Qué opina de extraer este método..."?

• Sea claro.
  Una retroalimentación puede malinterpretarse fácilmente, especialmente cuando se trata de expresar una opinión en lugar de compartir un hecho o una guía. Recuerde siempre aclarar eso de inmediato en su comentario.

No está claro: "Este código debería ser..."

Opinión: “Creo que este código debería ser…”

Realidad: “Siguiendo [nuestras directrices], este código debería ser…”.

• Explicar por qué.
  Lo que es obvio para ti, puede no serlo para otros. Nunca es demasiado explicar la motivación detrás de sus comentarios, por lo que el autor no solo entiende cómo cambiar algo, sino también cuál es el beneficio de ello.

Opinión: “Creo que este código podría ser…”

Explicó: “Creo que este código podría ser (…) porque esto mejorará la legibilidad y simplificará las pruebas unitarias”.

• Proporcione ejemplos.
  Cuando comparta una función de código o un patrón con el que el autor no esté familiarizado, complemente su sugerencia con una referencia como guía. Cuando sea posible, vaya más allá de los documentos de MDN y comparta un fragmento o un ejemplo de trabajo adaptado al escenario de código actual. Cuando escribir un ejemplo sea demasiado complejo, sea solidario y ofrezca ayuda en persona o mediante una videollamada.

Además de decir algo como “Usar el filtro nos ayudará a [motivarnos]”, también diga: “En este caso, podría ser algo como: [fragmento de código]. Puede consultar [un ejemplo en Finder.js]. Cualquier duda, siéntete libre de enviarme un ping en Slack”.

• Sé razonable.
  Si se comete el mismo error varias veces, prefiera dejar un comentario al respecto y recordar al autor que lo revise en los otros lugares también. Agregar comentarios redundantes solo crea ruido y puede ser contraproducente.

mantener el enfoque

Evite proponer cambios de código que no estén relacionados con el código actual. Antes de sugerir un cambio, pregúntate si es estrictamente necesario en ese momento. Este tipo de retroalimentación es especialmente común en los refactores. Es uno de los muchos compromisos entre eficiencia y eficacia que debemos hacer como equipo.

Cuando se trata de refactores, personalmente, tiendo a preferir mejoras pequeñas pero efectivas . Esos son más fáciles de revisar y hay menos posibilidades de tener conflictos de código al actualizar la rama con la rama de destino.

Establecer expectativas

Si deja una revisión de código a medio hacer, infórmele al autor, para que las expectativas de tiempo estén bajo control. Al final, también infórmele al autor si está de acuerdo con el nuevo código o si desea volver a revisarlo más tarde.

Antes de aprobar una revisión de código, pregúntese si se siente cómodo con la posibilidad de tocar ese código en el futuro. En caso afirmativo, es una señal de que realizó una revisión de código exitosa.

Aprenda a rechazar una revisión de código

Aunque nadie lo admite, a veces hay que rechazar una revisión de código. En el momento en que decide aceptar una revisión de código pero intenta apresurarla, la calidad del proyecto se ve comprometida, así como la mentalidad de su equipo.

Cuando acepta revisar el código de otra persona, esa persona confía en sus capacidades, es un compromiso. Si no tiene tiempo para ser un revisor, simplemente diga que no a su(s) colega(s). Lo digo en serio; no permita que sus colegas esperen una revisión del código que nunca se realizará. Recuerde comunicarse y mantener claras las expectativas . Sea honesto con su equipo y, aún mejor, con usted mismo. Cualquiera que sea su elección, hágalo de manera saludable y hágalo bien.

Conclusión

Con suficiente tiempo y experiencia, hacer revisiones de código le enseñará mucho más que solo conocimientos técnicos. Aprenderá a dar y recibir comentarios de los demás, así como a tomar decisiones pensando más en ellas.

Cada revisión de código es una oportunidad para crecer como comunidad e individualmente. Incluso fuera de las revisiones de código, recuerde fomentar una mentalidad saludable hasta el día en que sea algo natural para usted y sus colegas. ¡Porque compartir es lo que nos hace mejores!

Lectura adicional en SmashingMag:

• Trabajando juntos: cómo los diseñadores y desarrolladores pueden comunicarse para crear mejores proyectos
• Mejor colaboración al incorporar a los diseñadores al proceso de revisión del código
• ¿Qué podcasts deberían escuchar los diseñadores y desarrolladores web?
• Cómo elaborar el currículum de desarrollador web perfecto