Tiempo asignado a revisiones de código

13

Si estás haciendo revisiones de código

  • ¿Cuánto tiempo dedica a las revisiones de código, en comparación con la implementación?
  • ¿Cuánto de los cambios se someten a revisión de código?
  • ¿Crees que es mucho / debería ser más?

¿Hay estudios sobre la efectividad?

[editar] gracias a todos por las respuestas, es difícil elegir un "ganador" para esa pregunta, también hay mucha información valiosa en las otras respuestas.

    
pregunta peterchen 08.11.2010 - 23:02

5 respuestas

7

En mi trabajo tenemos lo siguiente procedimiento para revisiones de código. Hasta el momento, nos ha funcionado bien y descubrimos que es muy eficiente, especialmente en términos de horas de trabajo. Realmente no tenemos un tiempo específico asignado a las revisiones. Se debe revisar cada confirmación o combinación en el troncal, y demora todo el tiempo que el revisor lo apruebe.

Editar: El tiempo que lleva, por supuesto, depende de la magnitud del cambio. Las pequeñas características y correcciones de errores toman minutos. Grandes características nuevas, refactorizaciones o cambios que afectan a muchas partes del sistema pueden demorar la mitad de un día para revisar y otro día para abordar todos los problemas que surgen como resultado.

Para hacer que este sistema funcione, es crucial comprometerse con el troncal a menudo, para que los cambios sean de un tamaño manejable. No desea tener la situación cuando tiene que revisar el código de alguien por un año.

    
respondido por el Dima 08.11.2010 - 23:35
5

En cuanto a los estudios, el software Smart Bear le enviará un pequeño libro, Best Guardé los secretos de la revisión del código de pares , de forma gratuita. Tiene una serie de artículos sobre diversos aspectos de la revisión del código, incluidos estudios sobre cuánto tiempo deben dedicar y cuán efectivos son.

    
respondido por el Caleb Huitt - cjhuitt 09.11.2010 - 20:46
4

En nuestro proyecto, cada cambio significativo en el sistema es revisado por el líder del equipo o junto con otro desarrollador que será el "consumidor" principal del nuevo módulo. Hablamos por Skype y usamos Rudel en Emacs (un complemento para la edición colaborativa, básicamente permite que varios usuarios editen el mismo archivo en vivo), o TypeWith.me (Piratepad), o uno de nosotros comparte su pantalla en Skype.

Es difícil cuantificar esto, porque no se revisan los cambios mundanos, como nuevas vistas, páginas, etc. Revisamos nuevos módulos, actualizaciones importantes y refactorizaciones. En cuanto a los grandes cambios, la revisión del código puede llevar de un 10% a un 30% del tiempo, pero vale la pena.

Puedo decir que la programación de pares, cuando 2 programadores editan el mismo archivo al mismo tiempo, no solo en la misma computadora, es mucho mejor que la práctica habitual de la oficina de sentarse detrás del hombro.

Para cosas simples como convenciones de nombres y errores de alcance, usamos herramientas automáticas propias o de código abierto (jslint, pylint, pyflakes, pep8). Y no limitamos los compromisos y empujes: usamos Mercurial, que tiene una fácil ramificación y fusión (tengo que decir, más fácil que en Git). Los errores no son una cuestión de revisión de código.

Hacemos reuniones de equipo donde se anuncian los cambios y las cosas nuevas, pero no todos prestan atención. Probablemente deberíamos hacer un poco más de revisiones de código.

    
respondido por el culebrón 09.11.2010 - 00:58
2

No hay una respuesta correcta o incorrecta para esto. Pero como muchos de los que me han sugerido, si la revisión del código es realizada por un miembro del equipo externo [método altamente recomendado], podría ascender a aproximadamente 30% a 35% del esfuerzo de desarrollo. Pero si esto lo hace un miembro del equipo de proyecto interno que formó parte del equipo de desarrollo [no recomendado], esto se puede completar en aproximadamente dentro del 20% del tiempo empleado en el esfuerzo de desarrollo.

Nota: Encontré este hilo al buscar otra cosa y pensé que podría agregar algo de valor aquí. Por cierto, todo este cálculo de esfuerzo anterior se basa en mi experiencia laboral como administrador de compromisos en múltiples proyectos. Espero eso ayude.

    
respondido por el Nav 14.05.2018 - 06:07
0

Cada organización y base de código es diferente, por lo que es difícil obtener un valor para toda la industria.
Si usted es realmente serio, entonces debería comenzar a recopilar métricas. Es decir. Haga la revisión del código hasta que se haya completado satisfactoriamente, incluido el reproceso. Comience a recopilar esto en una base de datos (LOC, código de complejidad, lenguaje de programación, tiempo, etc.). Luego, también recopila métricas de tu tasa de defectos durante la prueba Mientras pueda reducir este código, la revisión debe pagarse sola. Si el defecto regresa de la prueba, recopile las métricas sobre cuánto tiempo se gastó en corregir defectos. Cree estos datos en su organización, cree líneas de base y podrá predecirlos con bastante precisión. Los términos para buscar aprendizaje adicional son Costo de calidad y Costo de calidad deficiente.

La única advertencia es que esto puede comenzar a ser burocrático y depende de la cultura de la organización.

    
respondido por el softveda 09.11.2010 - 11:23

Lea otras preguntas en las etiquetas