¿Deberían participar los Programadores Junior como revisores de código en los proyectos de los Programadores Senior?

El propósito principal de una revisión de código es encontrar defectos o problemas potenciales. Los participantes requeridos en la revisión deben ser las personas más adecuadas para identificar estos problemas, independientemente de su título o antigüedad.

Como ejemplo, si se está desarrollando una aplicación en Python y el ingeniero junior tiene más experiencia con el lenguaje Python que el ingeniero senior que escribió el código, entonces podrían ser un activo valioso para señalar métodos alternativos para hacer algo. , pero también pueden tener menos conocimiento del sistema en su conjunto.

Más allá de la experiencia en herramientas y tecnologías, también considere la experiencia en el dominio de la aplicación. Alguien con 20 años de experiencia pero solo 1 o 2 en la industria financiera puede ser ayudado por tener un desarrollador en general menos experimentado con solo 5 años de experiencia, todo en la industria financiera revisa su trabajo.

Invitar a miembros del personal con menos experiencia a observar y participar tanto como sea posible, el proceso de revisión del código también puede ser beneficioso para permitirles aprender una base de código, hacer preguntas y aprender sobre lo que se espera de ellos, no solo en las revisiones de código, Pero en el código que producen. Sin embargo, es probable que no desee que participen demasiadas personas (centrándose en cambio en las personas que pueden apoyar plenamente la revisión del código y su propósito) en el proceso.

Esto realmente se aplica a cualquier tipo de revisión: requisitos, diseño, código ...

  

¿Deberían participar los programadores junior como revisores de código en los proyectos de programadores senior?

Sí deberían. Es una buena experiencia de aprendizaje leer el código de otras personas. (Y eso se aplica tanto para el código bueno como para el malo. Aunque uno esperaría que el código de un desarrollador senior no fuera malo ...)

Obviamente, no es aconsejable solo hacer que los juniors realicen la revisión del código. Y no es prudente poner expectativas demasiado altas para los jóvenes en términos de lo que pueden encontrar. Sin embargo, también podría sorprenderse con las nuevas ideas que los programadores junior pueden traer a la mesa.

Otra Respuesta mencionó que los jóvenes estaban / sintiéndose intimidados. Eso NO es de lo que debería ser la revisión del código ... para los revisados o los revisores. Si eso sucede, su grupo debe cambiar la forma en que realiza las revisiones de sus códigos ... y tal vez los intimidadores deban ponerse en línea.

Yo agregaría que si un programador "Junior" no puede no entender un código de adultos mayores, eso en sí mismo es una buena medida del código. Bien, puede haber ocasiones en las que simplemente no sea posible escribir un código que todos puedan entender, pero espero que esas sean excepciones. Si solo 1 o 2 personas pueden entender el código, entonces qué sucede cuando esas personas no están disponibles y hay un problema con ¿Qué?

Dar a las personas nuevos desafíos les ayuda a desarrollarse; También puede ser que no todos estén preparados para revisar el código, pero parece dogmático insistir en que alguien tenga un título ( determinado por la política de recursos humanos y juegos ) antes de ser elegible para ayudar en una revisión.

Como otros han señalado, una revisión del código puede ser un proceso bidireccional; ayuda a todos a comprender el código base, por lo que comparte el conocimiento, ayuda a los jóvenes a aprender nuevas y mejores formas y técnicas de sus mayores y ayuda a los mayores a refinar su comprensión y al escribir para garantizar que todos puedan seguir el código que tiene más ojos que puede atrapar errores.

El propósito de las revisiones de código es detectar problemas que las pruebas no pueden detectar, como problemas de mantenimiento y casos de esquina. Yo diría que de muchas maneras los programadores junior son mejores adecuados para ese propósito:

• Tienen más tiempo disponible en general.
• Es más probable que lo tomen lentamente, línea por línea, por necesidad de entender el código.
• Cuando se habla de que se puede mantener el código, eso significa que todos en la compañía, no solo sus programadores principales. Eso significa que sus programadores junior deben poder entender el código para declararlo mantenible.
• A menudo tienen menos probabilidades de hacer suposiciones erróneas, confiando en que algo funciona de la forma en que creen que debería funcionar.
• Su educación en un lenguaje de programación es más reciente y es menos probable que se mezclen con años de experiencia en otro idioma. Por ejemplo, una persona mayor puede usar accidentalmente un hábito que tomó de C ++ que compila pero funciona de manera sutil y diferente en Java. Los jóvenes se dan cuenta de ese tipo de errores más fácilmente.
• Los revisores de código solo necesitan identificar problemas, no necesariamente proponer una mejor solución. A menudo harán comentarios en la línea de "No puedo entender cómo hacerlo mejor, pero esta parte es realmente confusa debido a toda la repetición". Un programador más experimentado puede realizar las mejoras fácilmente, aunque al principio no hayan notado el problema.

Eso no quiere decir que no haya otras formas en que los programadores sénior sean más adecuados para hacer revisiones, pero mi punto es que está haciendo un mal servicio si no está aprovechando al máximo la diversidad de su equipo.

Se les pedirá a los jóvenes que mantengan el código, es fundamental que puedan entenderlo.

A veces, los juniors son las únicas personas disponibles para revisar el código de los desarrolladores senior. ¿Debería el código esperar para ir al control de calidad (no sacamos nada del desarrollador sin una revisión del código y asumo que este tipo de revisión del código también) porque el jefe del senior está de vacaciones?

También les pedí específicamente a los jóvenes que revisaran el código algo cuando sabía que harían algo similar para un cliente diferente en breve o si sabía que habían trabajado en otra cosa similar o que tenían un conjunto de habilidades particular.

Si el código es bastante sencillo, a menudo recibo a una persona joven para que haga la revisión. ¿Por qué perder el tiempo de la persona mayor si la persona menor es bastante capaz de hacer el trabajo? Si los juniors se sienten intimidados al revisar el código de senior, haga que vean las piezas más fáciles inicialmente. Después de todo, no puedes dejar de ser joven hasta que dejes de sentirte intimidado.

A menudo he descubierto que si tengo que explicar el código a una persona joven que no lo entiende, veré un error que cometí (generalmente en una suposición) y que ningún revisor de código experimentado lo habría detectado porque El código se ejecuta pero no hace exactamente lo que se pretendía. Por lo tanto, el simple hecho de explicar las cosas a menudo ayudará al desarrollador a ver un problema sin que el revisor del código lo encuentre. Dado que las personas más experimentadas no suelen pasar por el código paso a paso, este tipo de cosas se encuentran más fácilmente cuando un joven hace la revisión.

Me parece que tener un junior involucrado en las revisiones tiene varios efectos positivos. Primero, les da más confianza cuando pueden entender el código de una persona mayor. Los hace aún más seguros cuando pueden encontrar un error en ese código.

Los expone a procesos de pensamiento fuera de los suyos y les permite ver otras formas de manejar las cosas. Incluso como persona mayor, esto me ha sucedido: ver una manera diferente de resolver un problema puede ser una revelación para nuevas posibilidades.

Les ayuda a aprender a leer el código de otras personas y les da la oportunidad de preguntar qué está haciendo el código mientras aún está fresco en la mente del autor. Eso es mucho mejor que tener que mantener la cosa seis meses después cuando el autor se haya ido hace mucho tiempo o está ocupado en otro proyecto y no tiene tiempo para preguntas.

Es bueno para los adultos mayores porque las preguntas exponen áreas potenciales donde el junior es débil y necesita orientación (para que puedan asumir más responsabilidades y darles más tiempo para que realicen otros tipos de tareas) o áreas donde el código es simple no está claro para nadie, excepto para el autor (lo que significa que tal vez ni siquiera esté claro para el autor dentro de un año cuando es necesario cambiarlo). También ayuda a los adultos mayores a darse cuenta de que los jóvenes pueden ser más inteligentes de lo que les han dado crédito por ser. Ayuda a mantener a todos en una base profesional. Después de todo, si excluyes a los juniors, entonces estás dando a entender claramente que no crees que sean capaces de entender el código que es psicológicamente desafortunado.

Los estudiantes juniors que revisan el código de adultos mayores pueden generar más respeto profesional en su organización. Los adultos mayores pueden darse cuenta de que han estado subestimando a los juniors y los juniors pueden darse cuenta de que los seniors saben más de lo que les dieron crédito. Los jóvenes a veces piensan que tienen mayores habilidades que las que tienen. Estar expuesto a un código que no pueden escribir es bueno para estas personas porque comienzan a darse cuenta de que tienen mucho más que aprender. También estimulará a los mejores para obtener las habilidades. En la escuela, a veces los estudiantes B no entienden por qué no obtuvieron una A hasta que alguien les muestra una muestra del nivel A del trabajo. Lo mismo ocurre con los juniors a los seniors en la revisión del código.

Mi respuesta es: A veces . Va a variar de un programador a otro y de una tarea a otra.

For:

• Si desea que esos juniors aprendan cómo hacer una revisión efectiva del código, entonces la mejor manera es que vean cómo lo hacen los seniors.
• Un programador junior puede tener más experiencia que uno senior en un idioma / dominio / etc en particular.
• Al obligar a los jóvenes a evaluar el código de los adultos mayores, inevitablemente aprenderán cosas. Sin embargo, la programación por parejas será una forma más efectiva de hacer esto, ya que cualquier pregunta que el junior pueda tener puede obtener respuestas inmediatas.
• El código de nadie es sagrado, y nadie es tan bueno que su código no debería ser revisado. Si no haces esto, ¿quién va a revisar el código de tus mejores chicos?
• No todos los juniors son iguales, y no todos los seniors son iguales. Es posible que a veces no haya muchas brechas, por lo que no se obsesione con los títulos de trabajo.

ENTREVISTA :

• Existe el riesgo de que las revisiones se atasquen con los problemas de los juniors.
• El nivel de conocimiento / habilidad requerido puede simplemente ir más allá de las capacidades del junior. Esto no solo desperdiciará su tiempo, sino que posiblemente también los desmoralizará.

Creo firmemente que todos los miembros del equipo deberían participar en ambos lados de las revisiones del código. Juniors deben revisar el código Senior, y viceversa. ¿Por qué ambos? Porque normalmente no se trata solo de si el código es "resuelve el problema". No puedo decir cuántas veces he tenido que explicarle un trozo de código a alguien y, de repente, se me ha ocurrido una forma mucho mejor de hacerlo al final de la explicación. Las revisiones de código tienen probablemente 3 propósitos:

1. Asegúrese de que el código sea correcto
2. Haga que el escritor piense en cómo otros verán su código
3. Obtenga los comentarios del lector sobre lo que podría mejorarse y un segundo par de ojos en general

Soy un junior y comúnmente reviso el código escrito para senior. Es una política general de la compañía: "todo obtiene el código revisado por alguien". Aprendo mucho de estos revisando su código y teniendo la oportunidad de hacer preguntas sobre por qué las cosas se hacen de cierta manera. Y a veces, propongo una forma más limpia de hacer un determinado código y tal. Mucho más raro que las personas que me dicen cómo mejorar mi código, pero ha ocurrido al menos una vez.

También importa cuán formales sean las revisiones de tu código. Los nuestros son muy informales y consisten en que "hey miren mi código" que se dice en todos los cubículos o en un canal privado de IRC. Me imagino que si revisa el código en un entorno más formal, el junior probablemente estaría mucho más preocupado al revisar el código de un senior.

Absolutamente, los ingenieros junior deben revisar el código de los ingenieros superiores, al menos parte del tiempo.

En mi experiencia, es bastante raro que el revisor en una revisión de código uno a uno realmente vea un error que el codificador original no encuentra, ya sea que el revisor sea senior o junior; el revisor ni siquiera tiene que ser humano . Por otro lado, es muy común que el codificador original reconozca un error al tratar de explicar el código, y cuanto más joven sea el revisor, más probable es que esto se deba a la profundidad de explicación requerida.

En mi opinión, algunos beneficios más a menudo pasados por alto de la revisión del código, que posiblemente sean más importantes a largo plazo que la captura de errores:

• Compartir el conocimiento de lo que realmente está sucediendo en el código base: "Espera, creo que Bill tuvo una clase que hace X, no necesitamos escribir una nueva".
• Compartir conocimientos de buenas técnicas y estilo de programación.

En estos dos aspectos, un revisor junior tiende a beneficiarse más que uno senior.

¡Los programadores junior deben estar realizando revisiones de código para sus colegas senior!

Sin embargo, no deberían ser el único revisor . Combínelos con un desarrollador más experimentado por revisión de código.

Hay una gran cantidad de beneficios:

• El autor se verá obligado a explicar más de su código. Hablar de su código es una de las mejores maneras para encontrar problemas con ella, o mejores formas de hacerlo.

• El autor encontrará debilidades en su código. Es más probable que el desarrollador junior esté confundido por algunos de los fragmentos más avanzados. Con frecuencia, estos son "demasiado difíciles" para su propio bien y podrían beneficiarse de la simplificación.

• El desarrollador junior aprenderá mejores prácticas de codificación. Las revisiones de código son una oportunidad para enseñar con el ejemplo.

• El desarrollador junior será un revisor de código más efectivo. La revisión de código es difícil . Cuanto más experimentados estén todos con revisiones de códigos, más rápidas y efectivas serán las revisiones de códigos.

• El desarrollador junior tendrá un conocimiento más profundo del código base. ¡Sé egoísta! Al jalar a los desarrolladores junior temprano, podrás entregárselos antes.

• El desarrollador junior se sentirá más involucrado. El desarrollador junior comenzará a ver el código "senior" (y sus colegas) como menos extranjero e intimidante. Este es un beneficio tremendo ya menudo pasado por alto por las revisiones de código.

• El desarrollador junior es un nuevo conjunto de ojos. No están tan adoctrinados como alguien que ha estado trabajando en el código base durante un largo período de tiempo. Es más probable que el desarrollador junior señale formas diferentes de lograr cosas a medida que hacen preguntas. ¡No ignore sus comentarios más salvajes sin al menos alguna consideración!

• Los desarrolladores senior son responsables. Con frecuencia he visto situaciones en las que los desarrolladores senior tienden a pasar por alto el código de los demás (confianza, pereza, etc.). Un par de ojos extra ayuda a desalentarlo.

El inconveniente que se debe tener en cuenta es que todas las partes involucradas dedicarán una buena cantidad de tiempo a realizar revisiones de códigos. Por lo tanto, puede ser un poco difícil de vender a la gerencia. Sin embargo, los beneficios superan completamente al ritmo más lento.

Se realiza una revisión del código para revisar el código, no para aprender. Si yo fuera un programador junior, me sentiría intimidado para revisar el código de senior.

Por otra parte, leer el código del senior es una excelente forma de aprender, siempre que el Senior esté disponible para responder todas las preguntas.

Dos alternativas podrían ser:

• permita que los Junior asistan a las reuniones de revisión de códigos y que cada asistente esté abierto a algunas discusiones de enseñanza / aprendizaje
• practicar la programación de pares