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

13

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

Creo que es muy beneficioso para todos nosotros revisar el trabajo de cada uno, sin embargo, después de aproximadamente 5 semanas de proceso, soy el único que realiza comentarios en la herramienta (BitBucket).

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

    
pregunta Graham S 20.10.2016 - 05:59

4 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 observando qué código es, con suerte, bueno; Si también encuentran problemas en su código, eso es un bono.

Si busca que su personal subalterno aprenda de las revisiones del código, lo más importante que debe hacer es crear un entorno donde el aprendizaje sea valorado 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é ha usado un determinado patrón o lo que sea, necesita preguntarse sin tener que sentir que está perdiendo el tiempo o el de los otros desarrolladores. .
  • El tiempo dedicado a aprender es un tiempo bien empleado . Usted quiere que sus desarrolladores junior pasen tiempo mirando el código y aprendan de él, porque los hará mejores y más productivos en el futuro. A menos que sea una solución crítica que deba revisarse ahora , anímelos a dedicar más tiempo, en lugar de menos, a las revisiones de códigos.
  • El personal superior no siempre tiene razón . Solo porque has estado haciendo esto por más tiempo no significa que tengas razón. Si creen que han encontrado un error, probablemente tengan razón. Si piensan que otro patrón de diseño sería apropiado para este fragmento de código, deben sentirse libres de decirlo sin recibir comentarios negativos.
respondido por el Philip Kendall 20.10.2016 - 11:09
5

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

"La revisión del código está parcialmente disponible para que conozca un poco mejor su código y para saber qué ocurre en su lado en caso de que algún día lo atropelle un camión y me ordenen que termine su carrera. Pero principalmente está ahí para que le expliques tu código a otra persona, porque cuando haces eso, compromete una parte diferente de tu cerebro, y muchas veces tu explicación para ellos, y sus preguntas o comentarios, pueden hacer que recuerdes algo que olvidó hacer en el código, o que podría hacer que se dé cuenta de una mejor manera de hacerlo más legible o de construirlo mejor. Eso conduce a un código más hermoso ".

Me gusta considerarlo como un espectáculo y un cuento. La gente puede mostrar su trabajo a sus compañeros. No se trata de que tus compañeros encuentren cosas mal en tu trabajo, lo que a nadie le gusta la sensación. Se trata de impresionar a tus compañeros con tu increíble código, que a todos les gusta la sensación.

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

    
respondido por el CommaToast 20.10.2016 - 07:49
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 alentador y que nadie recibirá una paliza por tener un error en su código.

Tener un trabajo significa asumir responsabilidad y orgullo en 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 una parte del grado. Los comentarios deben ser elaborados en. "Estoy de acuerdo" no es aceptable.

La revisión del código debería mejorar el código. Dependiendo de su situación, podría medirse por los números de ventas, las quejas de los usuarios o alguna otra calificación si escribe un código para uso interno. La realidad es que su código tiene algún propósito y su equipo debe medirse según qué tan bien cumplen ese propósito. Aquellos que determinen que contribuyen al éxito, pueden compartir proporcionalmente las recompensas.

Enfocarse en liberar código de calidad. El objetivo no es que todos se sientan bien consigo mismos al evitar los insectos. Escribo código mal; Tengo que arreglar el código malo. Eso es trabajo y vida. Odio arreglar errores, así que trato de evitarlos. Me enorgullezco de mi trabajo, así 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.

    
respondido por el JeffO 20.10.2016 - 12:55
-3

El proceso: Alguien quiere cometer sus cambios. Alguien es asignado como el revisor y revisa los cambios. Luego los cambios revisados y arreglados pasan a prueba.

Si las pruebas encuentran errores introducidos en el cambio, el autor y el revisor son igualmente culpables.

Por lo tanto, hacer una revisión sin ningún comentario te llevará a problemas a menos que el código sea perfecto.

    
respondido por el gnasher729 20.10.2016 - 08:18

Lea otras preguntas en las etiquetas