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


55

Uno de los miembros de mi equipo, un programador junior, tiene habilidades de programación impresionantes para su nivel de experiencia.

Y durante las revisiones de código, creo en enfatizar el aprendizaje, no señalar errores.

Pero, ¿deberían participar los programadores junior en revisiones de código para programadores más senior? ¿O las revisiones de códigos deben ser atendidas solo por programadores con la experiencia correspondiente?


54
¿De qué se tratan todas estas cosas "junior" y "senior"? OMI, si es o no es un programador calificado para revisar el código de otras personas debe ser determinado de acuerdo con la capacidad y experiencia - no título ....
Hormiguero

23
Y el título normalmente debe determinarse de acuerdo con la capacidad y la experiencia. Si ese junior es lo suficientemente bueno como para revisar el código de los seniors, es hora de cambiar su título.
SuperM

18
Pero a veces este título está determinado por la política y los juegos de recursos humanos :)
Michal Franc

44
¿Qué quieres decir exactamente con "programadores junior"? ¿Estas personas tienen menos experiencia en la aplicación o simplemente menos experiencia en la industria? En mi experiencia, es posible que un miembro del personal junior sea la persona más experimentada en un proyecto dado porque han trabajado en él por más tiempo o más recientemente.
Thomas Owens

44
@ThomasOwens, por "programadores junior", me refiero a las personas con menos experiencia en la industria.
Md Mahbubur Rahman

Respuestas:


62

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 al señalar métodos alternativos para hacer algo, pero También puede tener menos conocimiento del sistema en su conjunto.

Más allá de la experiencia en las 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 recibir ayuda si un desarrollador en general menos experimentado con solo 5 años de experiencia 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 conocer lo que se espera de ellos no solo en las revisiones de código, sino también 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 completamente 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 ...


44
+1 para "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". Y también por una excelente respuesta.
Md Mahbubur Rahman

6060
"El propósito principal de una revisión de código es encontrar defectos o problemas potenciales". Totalmente en desacuerdo. El propósito principal de una revisión de código es compartir conocimientos; El segundo propósito de una revisión de código es establecer un estándar de codificación; cualquier error encontrado durante la revisión es más suerte que juicio. programmer.97things.oreilly.com/wiki/index.php/Code_Reviews
pdr

8
@pdr Se debe establecer un estándar de codificación mucho antes de escribir la primera línea de código. Si está utilizando revisiones para establecer el estándar, es demasiado tarde. Puede ser un buen momento para adaptar el estándar de codificación a medida que se desarrolla: puede usar revisiones para señalar debilidades o sugerir mejoras al estándar, pero no puedo imaginar comenzar un proyecto de desarrollo sin algún estándar (incluso si es solo las pautas sugeridas por el lenguaje).
Thomas Owens

55
¿Cómo sabe qué poner en los estándares de codificación antes de que comience el proyecto y quede claro (a través de la revisión del código) que diferentes miembros del equipo abordan el mismo problema de diferentes maneras? No estamos hablando de mayúsculas en nombres de métodos, donde generalmente hay estándares de idioma, estamos hablando de cosas como NUnit vs MSTest; patrones de repositorio; la capacidad de decir "Oye, ya escribí un contenedor para clientes de WCF. Echa un vistazo al mío, toma lo mejor de cada uno y conviértelo en un estándar". Esto solo viene de revisiones de código y es la mejor razón para hacerlo.
pdr

44
El marco de prueba de unidad fue probablemente un mal ejemplo, pero es común, por ejemplo, dos desarrollos diferentes que requieren que se descomprima un archivo. Dos desarrolladores diferentes pueden usar bibliotecas diferentes porque las han usado antes. No puede tener TODAS estas discusiones por adelantado o quedará atrapado en más reuniones que desarrollo. El intercambio de conocimientos, a través de la revisión de código, es lo más importante para asegurarse de que estos problemas no se propaguen.
pdr

81

¿Deberían participar los programadores junior como revisores de código en los proyectos de los 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 que solo los juniors hagan la revisión del código. E imprudente poner expectativas demasiado altas en los juniors en términos de lo que pueden encontrar. Sin embargo, también podría sorprenderse con las nuevas ideas que los programadores junior pueden aportar.


Otra respuesta mencionó que los jóvenes estaban / se sentían intimidados. Eso NO es de lo que debería tratarse la revisión de código ... ni para el revisado ni para los revisores. Si eso está sucediendo, su grupo necesita cambiar la forma en que revisa sus códigos ... y tal vez los intimidadores deban alinearse.


Creo que lo que quiere decir Mouviciel es que el código de las personas mayores puede ser intimidante, no las personas mayores en sí (si ese es el caso, entonces sí, el equipo tiene problemas más serios que quién revisa el código).
Yannis

66
@YannisRizos - 1) No lo leo de esa manera. 2) Ahí es donde entra "es imprudente esperar mucho" . Si el código del senior es "intimidante", entonces es especialmente bueno para el desarrollo del junior tratar de leerlo / entenderlo.
Stephen C

1
Aprender cómo piensan los programadores senior es otra parte valiosa de las revisiones de código para desarrolladores junior. Cuando era un desarrollador junior, el código tenía más sentido una vez que el desarrollador senior lo revisó conmigo.
Michael Shopsin

38

Yo agregaría que si un programador "Junior" no puede entender el código de una persona mayor, entonces en sí mismo es una buena medida del código. Bien, puede haber momentos en los que simplemente no es posible escribir código que todos puedan entender, pero con suerte esas son 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 ¿eso?

Dar a las personas nuevos desafíos les ayuda a desarrollarse; También podría ser que no todo el mundo está preparado para revisar el código, pero parece dogmático insistir en que alguien tiene un título ( determinado por la política y los juegos de Recursos Humanos ) antes de que sean elegibles para ayudar en una revisión.

Como otros han señalado, una revisión de código puede ser un proceso bidireccional; ayuda a todos a comprender la base del código, 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, tienen más ojos que pueden atrapar errores


66
Ahora esa es una buena oración de apertura.
pdr

Si el código está usando técnicas más avanzadas (por ejemplo, usando operaciones de conjuntos en lugar de matrices y bucles), entonces lo que sucede es que alguien en el equipo levanta su juego.
Kevin Cline

1
Al hacer revisiones de código, es un indicador extremadamente fuerte que el código necesita un comentario o dos si alguien tiene que preguntar qué hace un fragmento de código en particular.
Bryan Anderson el

24

El propósito de las revisiones de código es detectar problemas que las pruebas no pueden detectar, como problemas de mantenibilidad y casos de esquina. Yo diría que de muchas maneras los programadores junior son más 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 habla de que el código se puede mantener, eso significa que todos en la empresa, no solo sus principales programadores. Eso significa que sus programadores junior deben poder entender el código para declararlo mantenible.
  • A menudo son menos propensos a hacer suposiciones erróneas, confiando en que algo funciona de la manera que suponen que debería funcionar.
  • Su educación en un lenguaje de programación es más reciente y es menos probable que se confunda con años de experiencia en otro idioma. Por ejemplo, un senior puede usar accidentalmente un hábito que aprendió de C ++ que compila pero funciona sutilmente diferente en Java. Los juniors 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 hacen comentarios en la línea de "Realmente 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 fácilmente las mejoras, aunque al principio no haya notado el problema.

Eso no quiere decir que no haya otras formas en que los programadores senior sean más adecuados para hacer revisiones, pero mi punto es que estás perjudicando si no estás aprovechando al máximo la diversidad de tu equipo.


13

A los jóvenes se les pedirá a menudo 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 esperar el código para pasar al control de calidad (no eliminamos nada del desarrollador sin una revisión del código y supongo que también este tipo de revisión del código) porque el jefe del senior está de vacaciones?

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

Si el código es bastante sencillo, a menudo hago que una persona menor 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 seniors, pídales que vean las piezas más fáciles inicialmente. Después de todo, no puedes dejar de ser junior hasta que dejes de sentirte intimidado.

A menudo he descubierto que si tengo que explicar el código a una persona menor que no lo comprende, veré un error que cometí (generalmente en una suposición) y que ningún revisor de código experimentado habría detectado porque el código se ejecuta pero no hace exactamente lo que se pretendía. Entonces, 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 con más experiencia no suelen pasar por el código paso a paso, este tipo de cosas se encuentran más fácilmente cuando un junior hace la revisión.

Me parece que tener junior involucrado en las revisiones tiene varios buenos efectos. 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 de la tercera edad, esto me ha sucedido: ver una forma diferente de resolver un problema puede abrirme los ojos a 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 mantenerlo seis meses después, cuando el autor se fue 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 joven es débil y necesita tutoría (para que puedan tomar más responsabilidad y darles a los adultos mayores más tiempo para realizar otros tipos de tareas) o áreas donde el código simplemente no está claro para cualquiera excepto el autor (lo que significa que puede que ni siquiera esté claro para el autor dentro de un año cuando deba cambiarse). También ayuda a las personas 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 posición profesional. Después de todo, si excluye a los juniors, está claramente insinuando que no cree que sean capaces de entender el código que es psicológicamente desafortunado.

Los juniors que revisan el código de seniors pueden generar más respeto profesional en su organización. Los adultos mayores pueden darse cuenta de que han estado subestimando a los jóvenes y los jóvenes pueden darse cuenta de que los adultos mayores 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 al 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 de trabajo A. Lo mismo con juniors a seniors en la revisión de código.


7

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

Por:

  • Si desea que esos jóvenes aprendan cómo hacer una revisión efectiva del código, entonces la mejor manera es que vean cómo lo hacen los mayores.
  • Un programador junior podría 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 mayores, inevitablemente van a aprender cosas. Sin embargo, la programación en pareja será una forma más efectiva de hacerlo, ya que cualquier pregunta que pueda tener el junior puede obtener respuestas inmediatas.
  • El código de nadie es sagrado, y nadie es tan bueno que su código no debería revisarse. Si no haces esto, ¿quién revisará el código de tus mejores chicos?
  • No todos los juniors son iguales, y no todos los seniors son iguales. A veces puede que no haya mucha brecha, así que no te obsesiones con los títulos de trabajo.

En contra:

  • Existe el riesgo de que las revisiones se atasquen sin problemas de juniors.
  • El nivel de conocimiento / habilidad requerido podría simplemente superar las capacidades del junior. Esto no solo perderá su tiempo, sino que posiblemente también los desmoralizará.

5

Creo firmemente que todos los miembros del equipo deberían participar en ambos lados de las revisiones de código. Los juniors deben revisar el código de Senior y viceversa. ¿Por qué ambos? Porque generalmente no se trata solo de si el código "resuelve el problema". No puedo decirte cuántas veces he tenido que explicarle un código a alguien y de repente se me ocurre 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 generales

Soy un junior y comúnmente reviso el código escrito senior. Es una política general de la empresa "alguien revisa todo el código". 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 cierto código y tal. Mucho más raro que las personas que me dicen cómo mejorar mi código, pero ha sucedido al menos una vez.

También importa cuán formales sean sus revisiones de código. Los nuestros son muy informales y consisten en "oye, mira mi código" que se dice a través de cubículos o en un canal IRC privado. Me imagino que si revisas el código en un entorno más formal, el junior probablemente estaría mucho más interesado en revisar el código de un senior.


2

Absolutamente, los ingenieros junior deberían revisar el código de los ingenieros senior, 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 omite, ya sea que el revisor sea senior o junior; el revisor ni siquiera tiene que ser humano . Es muy común, por otro lado, que el codificador original reconozca un error al tratar de explicar el código, y cuanto más pequeño sea el revisor, más probable es que sea, debido a la profundidad de explicación requerida.

En mi opinión, algunos beneficios más a menudo pasados ​​por alto pasan por alto que posiblemente sean más importantes a largo plazo que detectar errores:

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

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


2

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

Sin embargo, no deberían ser el único crítico . Combínalos 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 a través de su código es una de las mejores maneras de encontrar problemas con él, o mejores formas de hacerlo.

  • El autor encontrará debilidades en su código. El desarrollador junior es más probable que se confunda con algunos de los fragmentos más avanzados. Con frecuencia, estos son "demasiado complicados" por 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 del código es difícil . Cuanto más experimentados estén todos con las 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 de la base del código. ¡Se egoista! Al atraer a los desarrolladores junior temprano, podrás dá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 extraño e intimidante. Este es un beneficio tremendo y a menudo ignorado de las revisiones de código.

  • El desarrollador junior es un par de ojos nuevos. No están tan adoctrinados como alguien que ha estado trabajando en la base del código durante un largo período de tiempo. Es más probable que el desarrollador junior señale diferentes formas de lograr cosas al hacer preguntas. ¡No ignores 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.

La desventaja a considerar es que todas las partes involucradas pasarán una buena cantidad de tiempo realizando revisiones de código. Por lo tanto, puede ser un poco difícil de vender a la gerencia. Sin embargo, los beneficios superan por completo el ritmo más lento.


0

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

Por otro lado, 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:

  • Deje que los jóvenes asistan a las reuniones de revisión de códigos y que cada asistente esté abierto a algunas discusiones de enseñanza / aprendizaje
  • practique la programación en pareja

77
Las revisiones de código pueden ser experiencias de aprendizaje. Dicho esto, estoy totalmente de acuerdo, ese no es su propósito principal. Idealmente, todos los miembros del equipo deberían estar involucrados, pero entiendo su punto, tomará un tiempo para que un desarrollador (verdaderamente) junior tenga la confianza suficiente como para señalar fallas (suponiendo que pueda identificarlas primero, lo cual también es algo que no haría). Sinceramente, espere que un junior revise el código de un senior).
Yannis

El OP dijo explícitamente que el programador junior tiene buenas habilidades. Menos experiencia no siempre significa revisiones de código de menor calidad.
Cascabel

@Jefromi: El OP dijo explícitamente que él / ella quiere establecer el propósito de la revisión del código para el aprendizaje. Solo digo que esto no es para lo que están destinados.
Mouviciel

Hm, creo que entendemos el OP de manera diferente: la publicación dice énfasis en el aprendizaje, pero también dice "involucrados como revisores de código", lo que implica que el programador junior no es la única persona.
Cascabel
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.