¿Cómo alentar a los desarrolladores junior a participar en la revisión de código?

Actualmente estoy trabajando como desarrollador senior con 3 juniors debajo de mí y he introducido un proceso de revisión de código para ayudar a gestionar la calidad del código que entra en producción.

Siento que es muy beneficioso para todos nosotros revisar el trabajo de los demás, sin embargo, después de aproximadamente 5 semanas del proceso, soy el único que hace comentarios en la herramienta (BitBucket).

Creo que hay problemas culturales en parte en el trabajo, y tal vez una reticencia natural en caso de que sus comentarios sean incorrectos, pero ¿hay alguna manera de ayudar a los jóvenes a sentirse más cómodos criticando el trabajo mío y de los demás?

Para mí, la pregunta aquí es "¿qué estás buscando para que tus desarrolladores junior salgan de las revisiones de código?". Para mí, potencialmente lo más importante es que los desarrolladores junior aprendan mirando lo que es un buen código; si encuentran problemas en su código también, es una ventaja.

Si está buscando a su personal junior para aprender de las revisiones de códigos, lo más importante que debe hacer es crear un entorno donde se valore el aprendizaje y no se vea como una pérdida de tiempo. Esto significa una serie de cosas:

• No hay tal cosa como una pregunta estúpida . Si alguien no entiende un poco de código, por qué usó un cierto patrón o lo que sea, debe sentirse libre de preguntar, sin que se le haga sentir que está desperdiciando su tiempo o el de los otros desarrolladores. .
• El tiempo dedicado al aprendizaje es un tiempo bien empleado . Usted quiere que sus desarrolladores menores pasen tiempo mirar el código y aprender de ella, porque va a hacer mejor, el personal más productivo en el futuro. A menos que sea una solución crítica que deba revisarse ahora , aliéntelos a dedicar más tiempo, en lugar de menos, a las revisiones del código.
• El personal superior no siempre tiene la razón . El hecho de que haya estado haciendo esto por más tiempo no significa que tenga razón. Si piensan que han encontrado un error, probablemente tengan razón. Si piensan que otro patrón de diseño sería apropiado para este bit de código, entonces deben sentirse libres de decirlo sin recibir comentarios negativos.

Tenga reuniones de revisión de códigos en persona a la hora establecida cada semana. Le vendí esto a mi compañero de equipo de esta manera (en realidad somos ambos desarrolladores senior, pero lo que sea):

"La revisión del código está parcialmente ahí para que yo pueda conocer un poco mejor tu código y saber qué sucede en tu lado de las cosas en caso de que algún día te atropelle un camión y me ordenen terminar tu sprint. Pero principalmente es allí para que le expliques tu código a otra persona, porque cuando haces eso, involucra una parte diferente de tu cerebro, y muchas veces tu explicación a ellos, y / o sus preguntas o comentarios, pueden hacerte recordar algo que olvidaste hacer en el código, o podría hacer que se dé cuenta de una mejor manera de hacerlo más legible o diseñarlo mejor. Eso lleva a un código más hermoso ".

Me gusta pensar en ello como un show-and-tell. La gente puede mostrar su trabajo a sus compañeros. No se trata de que tus compañeros encuentren cosas incorrectas en tu trabajo, lo que a nadie le gusta sentir. Se trata de impresionar a tus compañeros con tu increíble código, que a todos les gusta sentir.

Sin embargo, creo que usar herramientas de revisión de código donde no hay interacción humana, no hay reunión en una habitación, no hay pizarra ... se convierte en otra "cosa" molesta que hacer. No es que no debería haber tales herramientas, pero deberían ser algo a lo que recurra si, durante la reunión de revisión de código, se da cuenta de que podría ser necesaria una revisión más profunda de una determinada sección de código. Luego, puede asignar a uno de los desarrolladores junior para que revise el código del otro en un área determinada.

Puedes ayudar dando un buen ejemplo. No puedes ponerte a la defensiva cuando alguien señala tus errores. Haga una revisión del código en su propio código y observe las áreas de mejora. Comparte esto con el equipo. Eventualmente, aprenderán que esto es alentado y que nadie recibirá una paliza por tener un error en su código.

Tener un trabajo significa asumir la responsabilidad y el orgullo de su trabajo. Si la revisión del código es parte de eso, entonces la participación en la revisión del código debe incluirse en las evaluaciones. He tomado clases en línea donde la participación en discusiones en línea es parte de la calificación. Los comentarios deben ser elaborados. "Acepto" no es aceptable.

La revisión del código debería mejorar el código. Dependiendo de su situación, podría medirse por números de ventas, quejas de los usuarios o alguna otra calificación si escribe código para uso interno. La realidad es que su código sirve para algún propósito y su equipo debe medirse por lo bien que cumplen ese propósito. Aquellos que determine contribuyan al éxito, comparta proporcionalmente las recompensas.

Concéntrese en liberar código de calidad. El objetivo no es que todos se sientan bien consigo mismos evitando los insectos. Escribo mal código; Tengo que arreglar el código incorrecto. Eso es trabajo y vida. Odio corregir errores, por lo que trato de evitarlos. Me enorgullezco de mi trabajo, por lo que me molesta cuando mi código no funciona. Me siento mal por los usuarios o cualquier otra persona que tenga que tomarse su tiempo para señalar estas cosas y me motiva a querer arreglarlo.

Como nota al margen, si tiene un entorno donde nadie puede dar o aceptar críticas constructivas, tiene un problema.

El proceso: alguien quiere comprometer sus cambios. Se asigna a alguien como revisor y revisa los cambios. Luego, los cambios revisados ​​y corregidos pasan a prueba.

Si las pruebas encuentran errores introducidos en el cambio, entonces el autor y el revisor tienen la misma culpa.

Por lo tanto, hacer una revisión sin comentarios lo meterá en problemas a menos que el código sea perfecto.