Las revisiones de código a menudo causan controversia. Al preparar la conferencia, "Desaprendemos del comportamiento tóxico en la revisión de código" en la conferencia de AlterConf, estaba listo para escuchar un montón de objeciones y críticas. Pero no esperaba que la comunidad apoyara tanto la idea. Asumí resistencia, pero la comunidad me recibió muy bien y me aprobó.

Se me pidió que compartiera las diapositivas , pero ahora pensaba que las diapositivas en sí mismas eran de poca utilidad y estaban fuera de contexto: carecen de explicaciones. Por lo tanto, decidí publicar este artículo. Más tarde, los organizadores de la conferencia subieron un video .

A continuación se enumeran algunos tipos de comportamientos y recomendaciones de revisión de código improductivo sobre cómo hacer que el proceso sea más amigable y eliminar la toxicidad. Todos los modelos de comportamiento han sido probados por mí o en una empresa que conozco. En el pasado, esos pecados también me fueron traídos.

Comportamiento improductivo n. ° 1: comunicar la opinión como un hecho

No haga declaraciones si no puede hacer referencia a documentación, recomendaciones formales y ejemplos de código en apoyo de estas declaraciones. Las personas deben saber por qué se les pide que realicen cambios, y las preferencias personales de otro desarrollador no son un argumento suficientemente bueno.

En lugar de decir:

Este componente debe hacerse sin estado.

... es mejor proporcionar algo de contexto:

Dado que este componente no tiene métodos de ciclo de vida o de estado, puede hacerse sin estado. Esto mejorará el rendimiento y la legibilidad del código. * Aquí * alguna documentación.

La transferencia de opinión como un hecho a menudo se encuentra en discusiones sobre estilo y sintaxis. Estos son temas realmente importantes, pero no para revisiones de código, porque el estilo y la sintaxis no tienen nada que ver con el problema que el desarrollador resuelve inicialmente.

Es mejor llevar a cabo tales discusiones por separado y determinar el estilo para todo el equipo. Implemente linter y arreglos automáticos de código . Luego se referirá a estas recomendaciones de estilo, no a su opinión personal.

Es especialmente importante no dar su opinión como un hecho si tiene un rango y autoridad más altos en un equipo o empresa. El desarrollador tiene la impresión de que no tiene más remedio que cumplir obedientemente sus requisitos.

Comportamiento improductivo # 2: avalancha de comentarios

Cuando una persona comete un error, existe una buena posibilidad de que este error ocurra en varios lugares. Noté que los revisores a veces indican cada uno de los casos en lugar de dejar una nota detallada con enlaces a recursos útiles.

La consolidación de comentarios le permite enviar el mismo mensaje sin suprimir al autor. Una avalancha de comentarios duplicados sobre un tema parece una trampa.

No productivo y abrumador:



Múltiples comentarios para un error recurrente (espacios al final de la línea)

Una opción más útil:


Comentarios consolidados

Puedo entender que a veces es útil señalar cada lugar del error, ya que el comentario desaparece cuando se corrige en confirmaciones posteriores. Pero si el error ocurre muchas veces, es obvio que el desarrollador no estaba al tanto de una guía específica, y debería señalar los recursos correctos.

Comportamiento improductivo número 3: pedir a los ingenieros que resuelvan los problemas de otras personas, "mientras están aquí"

No solicite a los desarrolladores que se ocupen de problemas que no están directamente relacionados con el conjunto de cambios o el problema que este código está tratando de resolver. Incluso si un desarrollador expande o modifica código sucio con una gran cantidad de malas prácticas, no le pidas que limpie y repare este código extraño.

No propongo privar a los desarrolladores de la responsabilidad del código solo porque inicialmente no lo escribieron. De hecho, no es bueno decir algo como "El código de otra persona no es mi problema". Es más apropiado crear un ticket separado y una solicitud de extracción para corregir el código sucio. Por lo tanto, evita un fuerte aumento en el volumen del trabajo de alguien, resolviendo el problema con la deuda técnica.

TL; DR : No le pida al desarrollador que solucione los problemas "mientras están aquí". Si el código hace lo que se requiere en el ticket y no introduce nuevos problemas en la base del código, apruebe y luego cree un ticket para borrar la base del código.

Comportamiento improductivo # 4: hacer preguntas de condena

Evite hacer preguntas condenatorias como esta:

¿Por qué no acabas de hacer ____ aquí?

Esto implica que alguna solución simple debería ser obvia. Esto obliga al desarrollador a defenderse.

A menudo, estas preguntas condenatorias son simplemente demandas veladas. En su lugar, ofrezca una recomendación (con documentación y enlaces), omitiendo palabras duras.

Puedes hacer ____, que tiene la ventaja de ____.

Comportamiento improductivo n. ° 5: sarcasmo

No hay lugar para el sarcasmo en las reseñas. Como regla general, los comentarios sarcásticos no proporcionan contexto y retroalimentación efectiva. En cambio, describa el problema en detalle y brinde recomendaciones, pero deje de lado las bromas cáusticas.

Improductivo:

¿Has probado este código antes de enviarlo?

Útil

No ingresar un número negativo. ¿Podrías hacer esto, por favor?

Aquí hay otro comentario de ejemplo en una revisión de código que no es ni divertido ni útil:

No somos malvados, somos despiadados. Como puede ver, escribí "beep!" - Al importar cada archivo que tocas. Tenía en mente lo siguiente: "Su importación viola nuestra convención estándar, que presupone un cierto orden: primero, módulos integrados, luego terceros y luego el nivel del proyecto", pero esta frase es demasiado larga para escribirla en cada caso.

En el ejemplo anterior, "¡pitido!" - completamente inútil y sin sentido. Este es un humor pedante que no ayuda al autor.

Comportamiento improductivo # 6: Emoji en lugar de describir el problema

Al señalar problemas en el código, evite los emoticones con el pulgar hacia abajo o los emoji con un hombrecito repugnante. Es tan inútil como el sarcasmo, por las mismas razones. Los emoji son misteriosos, fáciles de malinterpretar. La gente está perdiendo el tiempo tratando de entender tus pensamientos.


No use emojis para indicar problemas de codificación

En cualquier caso, no debe tener una reacción emocional a los errores de programación.

Es bastante normal usar emoticones positivos, como "pulgar arriba" o "¡salud!", Pero no para indicar problemas, sino como respuesta a un buen código.


Los emoticones aprobados son geniales

Comportamiento improductivo # 7: no responda a todos los comentarios

Los autores también contribuyen a la toxicidad de la discusión. Si combina el código sin responder todos los comentarios, entonces esto es sorprendente para la persona: intentó ayudarlo y usted deja en claro que algunas reseñas no importan.

Si el comentario es irrelevante o no tomará medidas, solo explique brevemente por qué.

No ignores a tus colegas.


Combinando código sin responder a un comentario

Comportamiento improductivo # 8: Ignorar el comportamiento tóxico si proviene de los mejores profesionales

El comportamiento tóxico no debe ser ignorado o subestimado solo porque el desarrollador es un excelente profesional y un empleado extremadamente productivo. Aunque hace un trabajo fantástico, es importante tener en cuenta que su comportamiento tóxico conduce al estrés y al agotamiento de otros desarrolladores.

Experiencia con una persona que exhibe un comportamiento tóxico:

Otros encontrarán que trabajar con esta persona agota y desmotiva. Harán cualquier cosa para evitar interactuar con él, incluso si afecta negativamente su capacidad para realizar tareas. Se interrumpirán las comunicaciones en toda la organización y los empleados comenzarán a buscar trabajo en otros lugares. Si bien enfrenta las consecuencias de una fuga de talentos y proyectos sin éxito, este desarrollador en particular continuará trabajando con calma como si nada hubiera pasado. - Joseph Gefro

Si no se toman medidas para rectificar la situación, son posibles consecuencias graves: los desarrolladores estarán sobrecargados, atacados y desmotivados. Comenzarán a temer la retroalimentación, que de hecho debería ayudarlos a crecer.

Personalmente, me sentí muy preocupado cada vez que recibía un correo electrónico con comentarios sobre mi solicitud de extracción de un ex colega (conocido por sus críticas tóxicas y poco útiles). Aunque el comportamiento tóxico afecta a todos de manera diferente, definitivamente nadie se beneficia de esta toxicidad.

Nota : Quiero dejar en claro que si el desarrollador no pudo resistir y una vez mostró tal comportamiento, esto no lo hace "tóxico". Estamos hablando de insultos repetidos y comentarios cáusticos.

Prácticas útiles de revisión de código

A continuación se presentan algunas recomendaciones que se aplican a cualquier comunicación normal, aunque aquí hablamos en el contexto de la programación y las revisiones de código.

Comportamiento útil # 1: use preguntas o recomendaciones para construir el diálogo

Nunca le pida a la gente que haga correcciones o preguntas de desaprobación, porque esto interfiere con el diálogo entre usted y la otra persona.

¿Por qué no combinaste estas conversiones en un archivo con constantes?

Formalmente, esta es una pregunta, pero no crea un diálogo entre usted y el interlocutor. Simplemente lo hace defenderse. En cambio, pregunte qué piensa la otra persona sobre su decisión, por ejemplo:

¿Qué opinas de convertir estas conversiones en un archivo constante? Hay bastantes, por lo que un archivo separado puede tener sentido en este momento.

... o hacer una recomendación:

En este archivo tiene muchas llamadas de traducción para la "función x". Puede tener sentido crear un archivo separado con sus constantes.

Comportamiento útil # 2: colaborar, no esconderse

Cuando programan juntos, tienen que estar cerca, hacer preguntas, discutir y señalar recursos.

"... Cuando quieres ayudar o trabajar juntos, debes estar completamente involucrado, no solo intervenir a veces" - Recurse Center Guide

Comportamiento útil # 3: responder a cada comentario

Si usted como autor no planea aplicar el consejo de un revisor, simplemente tome nota al informarlo. No ignores a los que se toman el tiempo para ayudarte.

Por ejemplo:

Persona A: - ¿Qué piensas de crear una función auxiliar para esta llamada API? De lo contrario, todo está bien.

Persona B: esta línea no formaba parte de mi conjunto de cambios. Combinaré el código, crearé un ticket por separado en GitHub y lo escribiré en el plan de trabajo para nuestro grupo.

Comportamiento útil # 4: saber cuándo organizar una reunión cara a cara

Después de docenas de comentarios y soluciones propuestas, debe quedar claro que la comunicación en línea se ha vuelto improductiva para el problema en cuestión. Envíe una invitación a la reunión a todos sus colegas involucrados.

Por lo tanto, el grupo podrá tomar una decisión rápidamente y aplicarla.

Los problemas que toman horas y toneladas de comentarios generalmente se pueden resolver en unos pocos minutos de conversación productiva. - "Java puro"

Comportamiento útil # 5: Use las oportunidades de aprendizaje y no presuma

Antes de participar en una revisión de código, pregúntese:

¿Tu comentario realmente te ayuda a aprender o estás encontrando fallas?

Piensa en tu comentario. Recuerde que el objetivo de una revisión de código es enseñar y ayudar a otros desarrolladores a crecer. Esta no es una plataforma para actuaciones.

Comportamiento útil # 6: no mostrar sorpresa

Tenga cuidado de no mostrar sorpresa si una persona no sabe algo. No moleste a las personas porque ya deberían saber esta información. Por el contrario, siéntase libre de admitir que carece de experiencia en el tema; esta es una excelente manera de pedir ayuda.

Consulte la regla "No finja sorprendido" en el tutorial del Centro de recursos para obtener más información.

Comportamiento útil # 7: automatiza todo lo que puedas

Tiene poco sentido hablar de errores que pueden ser atrapados por linters, ganchos Git o pruebas automatizadas. Esta es una tonelada de comentarios adicionales que parecen ser quisquillosos. Las personas no son muy buenas para identificar tales errores y, por lo tanto, se han creado herramientas de automatización.

También hay herramientas para ejecutar pruebas automáticamente al agregar un nuevo código. Muestran advertencias si un conjunto de cambios viola una de las pruebas. Por ejemplo, TeamCity y Jenkins CI.

Además, use ganchos Git para ejecutar pruebas y linters en el nuevo código. Interceptarán el commit si encuentran errores.

Deje que la herramienta indique problemas, para que las personas no tengan que hacerlo.

Comportamiento útil # 8: no superar el comportamiento tóxico

No es necesario adoptar un comportamiento tóxico en la revisión de su código, porque parece una venganza o algún ritual de novatadas para los nuevos desarrolladores.

Encuentre colegas que lo apoyarán.

Si observa revisiones de código improductivas, trate de decirle a un colega, hable directa y honestamente (si se siente seguro en su posición / empresa).

Comportamiento útil No. 9: gerentes, consideren cuidadosamente a los candidatos, escuchen al equipo y usen su autoridad

Los gerentes tienen grandes oportunidades para crear una atmósfera positiva y favorable en el equipo.

Reformulamos los consejos del artículo "Nocivo para desarrolladores tóxicos" :

• Evita que los desarrolladores tóxicos aparezcan en el equipo. Al contratar, preste atención no solo a la capacitación técnica. Descubra cómo el candidato colabora y se comunica. Analice críticamente su trabajo y vea cómo reacciona. Asegúrese de que cada candidato mejore la cultura de la empresa, y no solo se ajuste a ella.
  
• Cuando un desarrollador tóxico aún ingresó al estado o heredó, pídale a cada empleado una opinión al respecto en una conversación personal. Si el desarrollador es tóxico, aparecerá en las revisiones sobre él.
  
• Hable con un desarrollador tóxico. Dé ejemplos específicos de comentarios efectivos en una revisión de código. Trabaja continuamente con él, continúa recopilando información en conversaciones personales con sus colegas y gerente.
  
• No aísle el revelador tóxico. (*)
  
• Repita a los empleados sobre la necesidad de un ambiente amigable.

(*) Aunque el artículo propone aislar a los desarrolladores tóxicos, considero importante alentar al desarrollador tóxico a trabajar con el equipo, pero de manera más saludable. El aislamiento no resolverá el problema. Si le asigna un trabajo por separado, la toxicidad disminuirá a corto plazo, pero el desarrollador no renunciará a su comportamiento improductivo. Solo perderá el podio para demostrarlo.

Comportamiento útil # 10: establece el estándar mientras el equipo es pequeño y está creciendo

Los pequeños equipos pueden aceptar nuevas ideas e implementarlas. Incluso si no considera necesario establecer estándares, porque ahora no hay problemas, pero es importante mantener buenas prácticas de cooperación cuando llegue el reabastecimiento.

Comportamiento útil # 11: comprende que puedes ser parte del problema

Para crear un ambiente más favorable, es importante ser honesto contigo mismo y reflexionar sobre cualquier comportamiento ineficaz.

Como junior, noté un error en el código de alguien varias veces y estaba feliz, ¡porque podía dejar un comentario! Ahora entiendo que aproveché esta oportunidad para presumir, y no para ayudar. Necesita evaluar cuidadosamente sus acciones.

Creo que es útil para todos tomarse el tiempo para esta difícil introspección.

Y el ultimo ...

No estamos hablando del contenido de las reseñas, sino solo del tono.

Sé que las revisiones son importantes, y no estamos luchando contra ellas. No le pido que comprometa la calidad del código. La cultura benévola de la revisión del código y la alta calidad del código no deben ser mutuamente excluyentes.

Solo espero que las personas tomen medidas para proporcionar comentarios constructivos y efectivos y crear condiciones más favorables en las que los desarrolladores se sientan cómodos, aprendan, crezcan y no tengan miedo de cometer errores. Todos podemos mejorar juntos.