¿Deberíamos intentar revisar todo nuestro código?

18

Actualmente estamos modificando el proceso de desarrollo y me pregunto si deberíamos tratar de mantener un 100% de nuestros compromisos revisados ​​por pares.

¿Cuál es su experiencia con respecto a las revisiones de código?

  • ¿Tiende a pasar "mucho" tiempo con ellos (digamos 1/2 horas por día), o simplemente pasa por encima de 5/10 minutos como máximo?
  • ¿Tiene una cantidad fija de tiempo para pasar por día / semana / sprint / proyecto?
  • Más importante aún, ¿cree que el objetivo debería ser que el 100% del código sea revisado por pares o que el 100% no sea necesario?
code-reviews Simeon
fuente
Intenta tocar el 80% del código con el 20% del esfuerzo. Invierta en las mejores herramientas automatizadas que el dinero puede comprar.
Trabajo
2
Las herramientas automatizadas son geniales, pero se vuelven inútiles a menos que tenga el tiempo y los recursos para mantener todas las pruebas actualizadas.
Kieren Johnstone

Respuestas:

19

Tenemos una tarea de 'Revisión de código' en cada historia. Idealmente, alguien que no esté involucrado en el desarrollo de esa historia revisará todos los cambios de código asociados con esa historia. Funciona bien.

¿Un montón de tiempo? No mucho, depende de la cantidad de código: estamos buscando errores obvios, errores tipográficos, comprobación de la cordura de la lógica básica, excepciones no detectadas, etc.

Es un paso de calidad que encuentra errores, por lo tanto tiene algún valor. Asignar tiempo puede no ser la mejor manera de hacerlo: ¿qué tal si algo es bastante complejo, debería revisarse en código?

Por cierto, es importante que alguien más revise el código.

Kieren Johnstone
fuente
3
"Por cierto, es importante que alguien más revise el código ...", ¿la pregunta implica que la misma persona que escribe el código debería revisarlo? Si hace donde? Me gustaría arreglar eso :)
Simeon
44
No, no es así, estaba siendo comprensivo y decía que era importante
Kieren Johnstone
55
@Simeon es en realidad una idea errónea muy común de que el propietario puede revisar su propio código. Socava toda la operación
Tom Squires
55
@TomSquires: Exactamente. Cuando ha estado trabajando con un fragmento de código durante mucho tiempo, puede volverse "ciego" a fallas obvias en él, porque lo ve como lo que se supone que es en lugar de lo que es. Estos problemas serán más fáciles de detectar para alguien que nunca antes haya visto el código. Los escritores tienen el mismo problema, y ​​al igual que los libros no se publican sin revisión, el código no debe publicarse sin revisión. También hay otros beneficios al hacer revisiones de código, por ejemplo, es bueno para transferir conocimiento entre los miembros de su equipo.
hammar
@hammar, por supuesto, tratar de encontrar a alguien que no haya escrito el código y que tenga tiempo para familiarizarse tan íntimamente con él que puedan revisarlo de manera útil, es un desafío
Peter Ajtai, el
12

Un problema más importante que la cantidad de revisiones que cubre su código es cuán efectivas son las revisiones. Si sus comentarios descubren pocos o ningún problema, alcanzar una cobertura total será inútil.

Primero trabaje para que sus comentarios tengan más efecto, luego decida sobre la cobertura.

Las revisiones deben realizarse no solo en el código, sino también en el diseño.



Además, las revisiones no reemplazan las pruebas y herramientas:

  • Las revisiones pueden ejecutar código seco
  • Las revisiones pueden incluir análisis de código
  • Las revisiones examinan la reutilización y la legibilidad
  • Las revisiones pueden examinar algunos aspectos de la eficiencia, sin embargo, esto no reemplaza la medición real del tiempo de ejecución y la búsqueda de cuellos de botella
  • Existen herramientas para el análisis de código estático.
  • Hay herramientas para probar las convenciones de codificación, no pierdas el tiempo de revisión en esto
  • Unidad, sistema y pruebas de integración código de ejecución húmeda
  • Las pruebas de unidad, sistema y pruebas de integración pueden repetirse automáticamente, las revisiones de código suelen ser únicas
  • Las pruebas unitarias deben tener una alta cobertura de código y probar tanto los principales escenarios de éxito como las condiciones finales, las revisiones de código solo pueden hacer esto parcialmente
  • Las pruebas de integración prueban la capacidad de las unidades o sistemas para trabajar juntos, la revisión de código no puede reemplazar esto
  • Las pruebas del sistema prueban la funcionalidad de un sistema completo, la revisión del código no puede reemplazar esto



Intenta dedicar una cantidad de tiempo preestablecida por mes (o por sprint) a las revisiones. Seleccione el código que desea revisar en el siguiente espacio dedicado utilizando una heurística como:

  • Código que puede contener un error no identificado que se informó
  • Código con eso recientemente ha tenido errores identificados dentro de él
  • Código con problemas de rendimiento (cuellos de botella)
  • Código escrito por nuevos desarrolladores
  • Código heredado que fue actualizado recientemente por alguien que no estaba familiarizado con él anteriormente
  • Código en nuevas áreas
  • Código existente sobre el que desea que los nuevos desarrolladores conozcan
  • Código que resuelve problemas complejos
  • Código identificado como complejo por herramientas de análisis

Y recuerde, está revisando código (o diseño o pruebas) y no autores.



Recomiendo los siguientes materiales de lectura:

Revisiones selectivas sin tarea
Los secretos mejor guardados de la revisión del código de pares

Danny Varod
fuente
5

Depende.

Depende de lo que esté haciendo su software:

  • Si controla un marcapasos electrónico o un transbordador espacial, definitivamente sí.

  • Si es un prototipo descartable, entonces probablemente no.

También depende de la cantidad de recursos que tenga, la experiencia de sus desarrolladores y lo que esté buscando en las revisiones de código. (Tenga en cuenta que el desarrollador promedio que revisa el código de otra persona probablemente notará problemas de estilo y perderá sutiles errores algorítmicos ... especialmente dado que la revisión del código es una tarea rutinaria).

Mi consejo sería guardar su esfuerzo de revisión de código para código donde la corrección es crítica y el costo de errores no detectados es alto.

Stephen C
fuente
5

Primero, debe responder esta pregunta: ¿Por qué revisa el código?

Con esa respuesta en la mano, puede averiguar qué código debe revisarse.

Algunas revisiones de código logran exactamente lo que las pruebas hacen o habrían hecho. Si ese es el objetivo de sus comentarios, acercarse al 100% es una buena idea si tiene pocas pruebas. Sin embargo, dejar que las herramientas de prueba hagan esto reduciría la necesidad de revisar todo el código.

La mayoría de las buenas críticas parecen centrarse en compartir el conocimiento y aumentar las capacidades de los desarrolladores en la revisión (ya sea el que escribió el código o los que lo revisaron). Con esto como una razón principal para las revisiones, asegurarse de revisar el 100% del código probablemente sea excesivo.

John Fisher
fuente
3

En un mundo perfecto, todo sería leído explícitamente por el autor y revisado por pares por al menos otra persona, desde las especificaciones de requisitos hasta los manuales de usuario y los casos de prueba. Pero las revisiones, incluso los simples controles de escritorio, toman tiempo y cuestan dinero. Esto significa que debe elegir lo que debe revisar y cuándo debe revisarlo.

Recomiendo priorizar las cosas para revisar, elegir cómo desea revisarlas e intentar revisar todo lo que pueda con el nivel de detalle apropiado. La priorización podría basarse en el tipo de artefacto, como indicar que los requisitos deben revisarse, el código de diseño y producción debe revisarse, y los casos de prueba pueden revisarse. Dentro de eso, también puede especificar que los componentes de alto riesgo o alto valor reciban una prioridad en la revisión, o tal vez una revisión más formal.

En cuanto al tiempo, todo se remonta a la prioridad que tiene el componente. Hubo momentos en los que pasé de 10 a 15 minutos revisando, y otras veces que varias personas leyeron el código individualmente y luego entraron a una sala para hacer un proceso de inspección más formal que dura de 30 a 45 minutos (dependiendo del tamaño de el módulo).

Al final, es un equilibrio entre tiempo, costo, alcance y calidad. No puede tenerlos todos, por lo que debe optimizar donde pueda.

Thomas Owens
fuente
3

Como sugerencia, si planea hacer alguna revisión, comparta algunas pautas sobre el alcance y el objetivo de la revisión para asegurarse de que las revisiones no causen fricciones innecesarias entre los miembros del equipo.

Los equipos coherentes construyen mejores proyectos. Las personas pueden perder relaciones por tonterías o por solicitudes de perfección. Siempre hay una persona que se queja de esto o aquello y molesta a los demás solo porque es así ...

Ninguna posibilidad
fuente
2

Reservo una hora por día para hacer revisiones por pares, pero no siempre lo requiero. Nuestro código base se comparte entre una docena de productos. Nuestra política es que un cambio trivial en el código exclusivo de un producto está bien para registrarse sin revisión. Los cambios más complejos de un producto requieren una revisión, pero puede ser tan informal como llamar a un colega a su escritorio para que lo revise nuevamente. Los cambios en el código compartido requieren una revisión más formal, incluidos los desarrolladores de otros productos. Creo que nuestra política logra un equilibrio bastante bueno en comparación con otras compañías para las que he trabajado.

Paso más tiempo por día en las revisiones que algunos de mis colegas con roles menos centrales, pero no considero que sea una cantidad de tiempo irrazonable, porque antes de la política de revisión, podría fácilmente perder más tiempo que eso rastreando errores que un desarrollador en otro producto introducido.

Karl Bielefeldt
fuente
¿Es eso un promedio? Limitar una revisión compleja a una hora parece extraño, y si no hay tanto para revisar ... bueno, no puedo ver cómo sería viable una hora al día.
Kieren Johnstone
Eso no es un límite. Establecí el tiempo en función de cuánto tiempo tardó, no al revés. Por lo general, puedo hacer 2 revisiones en una hora. Si lleva más tiempo que eso, sus registros son demasiado grandes, no está obteniendo suficiente revisión de diseño de antemano, o sus herramientas de revisión de código son demasiado engorrosas. Las revisiones de código son un cheque, no un rediseño.
Karl Bielefeldt
2

Hemos hecho 100% de revisiones para el código. Es mucho más barato que las pruebas, especialmente las pruebas de cobertura de código 100%. No dedicamos demasiado tiempo a ellos, revisarlos durante más de una hora por día se vuelve menos productivo. (30 minutos no es mucho).

A medida que esté haciendo cero en el proceso, mantenga notas. ¿Que encontraste? ¿Qué encontró QA más tarde? ¿Qué encontraron sus clientes? ¿Por qué escaparon esos bichos?

MSalters
fuente
77
¿Cómo es la revisión más barata que las pruebas automatizadas? Suponiendo que escriba una prueba una vez, revise una prueba una vez y tenga un conjunto de pruebas estable, debería gastar mucho menos tiempo y dinero ejecutando pruebas de lo que se necesita para realizar cualquier tipo de revisión (durante la vida del proyecto). Además, el objetivo de una cobertura de código del 100% es una pérdida de recursos, lo que podría ser la razón del mayor tiempo / costo de las pruebas. También cuestiono los 30 minutos en las revisiones: podríamos revisar un módulo durante 30 minutos, pero hay un tiempo de preparación para leer el código inicialmente, comprender su papel en el sistema y comentarlo.
Thomas Owens
Las afirmaciones de @MSalters no son desconocidas, aunque yo también soy escéptico con solo tomar 30 minutos. Solo he leído de un lugar donde fue el caso que la inspección fue más rentable que las pruebas unitarias automatizadas y fue la NASA. En ese caso, finalmente abandonaron las pruebas unitarias por completo porque era más barato inspeccionar manualmente el código. Por supuesto, la NASA todavía tenía una relación de probador 12: 1: desarrollador, por lo que también estaban haciendo muchas otras pruebas ...
Michael
2
@Thomas Owens: las pruebas unitarias encuentran errores simples. Los errores caros son aquellos en los que varias unidades se combinan de manera inesperada. Otro tipo de errores son los casos de esquina perdidos. Un desarrollador que perdió un caso tampoco escribirá una prueba unitaria para él, pero un segundo par de ojos lo detectará.
MSalters
@MSalters Es por eso que escribe pruebas automatizadas de integración y sistema, así como pruebas unitarias. Realmente, las únicas pruebas que pueden necesitar realizarse manualmente son las pruebas de aceptación. Y al revisar las pruebas una vez creadas, ayudaría a garantizar que se prueben los casos más críticos.
Thomas Owens
2

Realice revisiones periódicas del código principalmente para la creación de equipos y para compartir ideas sobre la implementación Puede aprender mucho de sus compañeros de trabajo de esta manera.

descifrador
fuente
Esto solo indica algunos beneficios. ¿Crees que encontrar errores es importante? Si es así, ¿cuánto?
JeffO
Por supuesto, encontrar errores es importante, pero el mayor beneficio es el conocimiento a largo plazo obtenido de las revisiones de código. Quizás un error fue creado por un mal enfoque que puede evitarse en el futuro
codificador
2

Requerimos una revisión del código de pares para cada check-in. Si no hay ningún par disponible, organizamos una revisión posterior al check-in. El revisor aparece en el comentario de control de control de fuente.

Estos no toman mucho tiempo, y dado que se hacen entre pares, no existe un aspecto tóxico entre adultos y niños.

Jim en Texas
fuente
2

La revisión de código es, IMO, necesaria. Tienes 99.999 ...% del tiempo no siempre va a ser correcto, por lo que debes asegurarte de que sea correcto. ¿Tengo un horario establecido? No. Pero me tomo el tiempo de revisar mi código. Normalmente tengo un colega que hace lo mismo.

Dinámica
fuente
1

Las revisiones de código pueden parecer desalentadoras, pero son una herramienta valiosa cuando se realizan correctamente. Serán su primera línea de defensa contra los errores de diseño e implementación. Si no está llevando a cabo revisiones de código en cada característica que implementa, debe comenzar lo antes posible.

En cuanto a cuánto tiempo dedicar a las revisiones por pares, una buena práctica es dejar entre el 5 y el 10% del tiempo total estimado de desarrollo para realizar y responder a la revisión del código.

Tenemos un documento técnico sobre la realización de revisiones de código efectivas que pueden ayudarlo a comenzar con el pie derecho. Es una guía paso a paso y analiza los problemas comunes que puede enfrentar y cómo resolverlos. Puede descargarlo de nuestro sitio web.

Katie B.
fuente