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

13

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?

Graham S
fuente
2
Me pregunto si esta podría no ser una mejor pregunta para Workplace.SE, pero mis 2 centavos como desarrollador junior. Mientras era pasante, estaba muy nervioso por participar en revisiones de código por varias razones: falta de habilidades, falta de familiaridad con la base de código, etc. Pronto descubrí que participar en la revisión de código ayudó con ambos aspectos ( especialmente familiaridad), y también fue muy útil al hacerme sentir que nuestra base de código era algo en lo que tenía un interés personal, por lo que quería contribuir. Definitivamente no siempre dejé buenos comentarios, pero no lo supe hasta que (cont.)
Dannnno
2
(cont) lo intenté, y me ayudó a trabajar mejor con el equipo en general. Creo que si intenta explicar por qué es útil para usted, el equipo y la base de código para que participen, incluso si sus comentarios son incorrectos; si sus comentarios son incorrectos, eso es casi mejor porque pueden aprender de ello.
Dannnno

Respuestas:

15

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.
Philip Kendall
fuente
Muchas gracias por el aporte, lo pensaré y lo discutiré en nuestro stand up mañana
Graham S
1
Yo agregaría: la forma de llegar a ser un experto es cometiendo errores y aprendiendo de ellos. Como cuestión práctica, podría ser útil para el Sr. desarrolladores para contar algunas historias de guerra sobre sus errores anteriores.
5

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.

Tostada Coma
fuente
+1 por involucrar a una parte diferente de tu cerebro. En mi experiencia, especialmente cuando era un desarrollador junior, el solo hecho de saber que mi código iba a ser revisado por pares me hizo prestar atención a los detalles que de otro modo podría haber ignorado.
Droide Lacónico
0

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.

JeffO
fuente
-3

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.

gnasher729
fuente
55
1) Asignar "culpa" por los errores es una excelente manera de hacer que su personal se vaya 2) Asignar la culpa al personal junior por no detectar errores escritos por el personal superior es doblemente malo.
Philip Kendall
2
@PhilipKendall Si mi código tiene un error, nadie tiene que culparme. Soy un profesional y me siento muy orgulloso y responsable de mi trabajo. ¿Es esto una especie de nueva era en la que nadie hace nada malo y todos obtienen un trofeo por participar?
JeffO
@PhilipKendall: No sé dónde trabajas ... Donde trabajo diré "qué error tan estúpido cometí" y el crítico dice "y también me lo perdí" y luego ambos nos reímos. "Culpar" significa asumir la responsabilidad, no pararse en la esquina con un sombrero de burro.
gnasher729
1
@ gnasher729 Sí. Pero nadie se "mete en problemas" por ello.
Philip Kendall