¿Cómo lidiar con alguien a quien no le gusta la idea de las revisiones de código?

Obviamente, si la gerencia se dedica a pasar tiempo con revisiones de código, entonces todos tienen que hacerlo.

Pero siempre hay esos tipos (o chicas) que se resisten con cada onza de su ser.

¿Cómo manejas de manera efectiva el manejo de este escenario cuando lo enfrentas como el revisor de pares?

Se resiste por miedo . Este condicionamiento puede ser el resultado de una (s) mala (s) experiencia (s) previa (s) sobre ser revisado, cuando era niño, en la escuela, en el trabajo o incluso en su equipo actual. En nuestras sociedades modernas, es muy común que confundamos el trabajo de alguien con su valor como ser humano. Es por eso que las revisiones en el trabajo no se perciben bien. Esa es también la razón por la que hablar en público en una de las fobias más extendidas (miedo al juicio).

Para evitar tal comportamiento, necesitará algo de psicología. Debes demostrarle a su cerebro de lagarto que no va a suceder (no será juzgado, humillado, asesinado, nada ...) desensibilizándolo a las revisiones de códigos.

Uno de los métodos más efectivos que encontré para desbloquear a alguien es pedirle que revise su código , antes de pedir que revise su código.

Después de un tiempo, proponle que lea su código para aprender de él y por qué no sugerir mejoras. Cuando encuentre algo que cambiar, tenga cuidado con lo que escribe. Entenderá que no hay nada que temer, y tomará la parte positiva del proceso de revisión solamente: aprender y aumentar su conocimiento .

Intentaría trabajar en parejas: formar un equipo que odie la idea con alguien a quien le guste y hacer que revisen el código del otro durante un par de semanas. Obviamente, esto puede o no ayudar, pero estar en ambos extremos de la revisión al menos dará una visión más completa del proceso. Tener un par trabajando juntos les permitirá familiarizarse con el estilo y los errores comunes de cada uno y les dará tiempo para realmente ayudarse mutuamente a mejorar, en lugar del sello de goma. Esto también puede ayudarlo a promover la programación de pares en su entorno de trabajo, ya que creo que puede ver una tendencia creciente no solo a revisar, sino también a recodificar o incluso planificar y codificar desde cero.

Mientras las partes desinteresadas estén dispuestas a intentarlo, esto podría ayudar. Si se niegan a considerarlo, no hay mucho que puedas hacer al respecto mientras estén en el equipo.

La respuesta de @ Pierre está encaminada para alguien que teme una revisión de código. Me puedo imaginar otra situación. Un programador estrella que siente que una revisión del código es una pérdida de tiempo porque el código alcanza un estándar aceptable de calidad y corrección. En este caso, pueden sentir que una revisión del código es una pérdida de tiempo y una caza de brujas. (Esa es una búsqueda de un problema cuando no existe ninguno).

En este caso, reorientaría el objetivo de la revisión. En lugar de que la revisión del código se trate de encontrar "problemas" en el código, trátelo como una búsqueda de objetivos de refactorización o posibles mejoras futuras, o características de diseño adicionales. De esta manera, tanto el codificador como el revisor están involucrados en el proceso y esperamos que este codificador capaz sienta que se está aprovechando el tiempo.

Francamente, esta pregunta no tiene ningún sentido si tiene una tienda bien administrada:

1) Si es parte del trabajo, debe hacerlo o es insubordinado. Alguien que se niega rotundamente a hacer parte del trabajo que debe hacer debe ser enlatado. La programación es un oficio y una profesión: los revisores y gerentes están ahí para ayudar a hacer el trabajo, no para tratar con niños mimados (de cualquier edad).

2) Si tiene un sistema de control de fuente bien administrado (que es imprescindible en cualquier tienda de software profesional), puede revisar su código, les guste o no. Entonces revise su código:

• Si es bueno, notifíqueles y déles una palmadita en la espalda, eso alentará la participación.

• Si no es bueno, también hágales saber. Esto debería tener el efecto de motivarlos a participar para defenderse. Si no es así, puede utilizar medidas punitivas: sanciones financieras, degradaciones de estatus, etc. Si a pesar de sus esfuerzos este empleado no se presenta, en mi opinión, tiene un mal empleado y se les debe mostrar la puerta.

¿Tienen algunas experiencias negativas en lugares donde las revisiones de código no se realizaron correctamente? Pueden tener preocupaciones legítimas.

Si no ven absolutamente ningún mérito para el ejercicio, pídales que sean pacientes y vean qué sucede con su código y, especialmente, como resultado de otros (si creen que son perfectos).

La revisión de código 'debería' mejorar el desarrollo, pero hasta que tenga un sistema que realmente funcione, ¿por qué alguien debería querer hacerlo?

Personalmente, creo que hay algunas peleas que no se pueden ganar con el 100% de la población.

Puedo ver suficientes razones por las cuales la programación de pares no funcionaría cuando alguien se ve obligado a hacerlo.

Pero las revisiones de códigos son diferentes: cambian su productividad, no necesariamente sus hábitos de trabajo.

La administración puede hacer varias cosas para reducir la resistencia debido a la productividad: 1) Aceptar la reducción de velocidad para todos los desarrolladores. 2) Proporcione las herramientas apropiadas para manejar la gestión y la fusión de múltiples versiones debido a los ciclos de revisión (por ejemplo, permitiendo que los desarrolladores tengan un repositorio local de git) de opiniones

Si lo hacen, es legítimo exigir que todos participen, en mi humilde opinión. La compañía para la que trabajo ahora tiene una fuerza global: simplemente no puede enviarla sin la aprobación del propietario. Y si bien esto ralentiza las cosas, previene muchos accidentes.

Utilizamos medidas técnicas para hacer obligatoria la revisión del código.

La forma en que introdujimos la revisión de código es que en nuestro control de código fuente, es imposible fusionar código que no haya sido firmado por otra persona que no sea la que lo empujó.

Despedirlos

Es así de simple: o obtienen un proyecto de hombre solitario o tienen que irse. Alejarlos de su equipo. No solo no están haciendo su parte, sino que erosionan la moral y las prácticas del equipo.

Ahora, si parece que tienes que despedir al 50% de tu equipo, entonces ...

Entender

¿Por qué algunos se niegan? ¿No tienen tiempo? ¿Están quemados? ¿Las reseñas sobre algo con lo que no tienen experiencia? ¿Creen que es una pérdida de tiempo? Si es así, ¿por qué?

La metodología ágil ayudará aquí: supongo que trabajas constantemente contra los silos (es decir, para reducir el factor del autobús), y las personas de tu equipo están involucradas en lo que otros hacen.

Trabaje para garantizar que las solicitudes de fusión individuales sean bastante pequeñas. Si se trata de más de 1 pantalla de cambios, necesita una conversación de pie o relámpago para explicar lo que se está haciendo. Si son 10 páginas, necesita una presentación con diapositivas y diagramas de arquitectura.

¿Todos en cuestión trabajan en el mismo proyecto?

¿El proyecto ya está enterrado bajo una montaña de deudas técnicas?

¿Creen en el proyecto y la mejora continua?