Tiempo asignado a revisiones de código

Si estás haciendo revisiones de código

• ¿Cuánto tiempo pasas en 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 demasiado / debería ser más?

¿Hay algún estudio 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.

En mi trabajo tenemos el siguiente procedimiento para las revisiones de código. Hasta ahora nos ha funcionado bien, y nos pareció que era muy eficiente en el tiempo, especialmente en términos de horas hombre. Realmente no tenemos un tiempo específico asignado a las revisiones. Todos los commits o fusiones con el troncal deben ser revisados, y el revisor demora todo el tiempo que sea necesario.

Editar: el tiempo que lleva, por supuesto, depende de la magnitud del cambio. Pequeñas funciones y correcciones de errores toman minutos. Las grandes características nuevas, refactorizaciones o cambios que afectan a muchas partes del sistema pueden tomar medio día para revisar y otro día para abordar todos los problemas que surjan como resultado.

Para que este sistema funcione, es crucial comprometerse con el tronco a menudo, de modo 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.

En lo que respecta a los estudios, el software Smart Bear le enviará un pequeño libro, Best Kept Secrets of Peer Code Review , de forma gratuita. Tiene una serie de artículos sobre diversos aspectos de la revisión de código, incluidos estudios sobre cuánto tiempo deben tomar y cuán efectivos son.

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 principal "consumidor" del nuevo módulo. Hablamos sobre skype y usamos Rudel en Emacs (un complemento para 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 las 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 del 10% al 30% del tiempo, pero vale la pena.

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

Para cosas simples como convenciones de nomenclatura y errores de alcance, utilizamos nuestras propias herramientas automáticas de código abierto (jslint, pylint, pyflakes, pep8). Y no limitamos los commits y los push: utilizamos Mercurial, que tiene ramificaciones y fusiones muy fáciles (debo decir que es 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 allí, no todos realmente prestan atención. Probablemente deberíamos hacer un poco más de revisiones de código.

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

Nota: Me encontré con este hilo al buscar otra cosa y pensé que podría agregar algún valor aquí. Por cierto, todo este cálculo de esfuerzo anterior se basa en mi experiencia laboral como gerente de compromiso en múltiples proyectos. Espero eso ayude.

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 realice satisfactoriamente, incluida la reelaboración. Comience a recopilar esto en una base de datos (LOC, complejidad del código, lenguaje de programación, tiempo, etc.). Luego, también recopile métricas sobre la tasa de defectos durante las pruebas. Siempre y cuando pueda reducir esta revisión de código, debe pagarse solo. Si el defecto regresa de la prueba, recopile métricas sobre cuánto tiempo se dedicó a solucionar los defectos. Cree estos datos en su organización, cree líneas de base y pueda predecirlos con bastante precisión. Los términos para buscar más aprendizaje son Costo de calidad y Costo de mala calidad.

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