La revisión del código va por detrás del ciclo de entrega / prueba

14

En nuestro proceso ágil tenemos Sprints de 2 semanas. Las tareas se entregan diariamente (compilaciones diarias), y el equipo de prueba completa sus pruebas inmediatamente al día siguiente o incluso el mismo día.

También tenemos revisiones de códigos de desarrollo, que requieren algo de tiempo (1-2 horas), por lo que se programan 3 veces a la semana: de lunes a miércoles y viernes. Los desarrolladores se reúnen y sugieren cómo mejorar / refactorizar el código.

Nuestro problema es que, cuando aparecen los Elementos de acción después de una revisión de código, la mayoría de las tareas ya se han probado. Los probadores no quieren volver a probar lo que ya pasó sus pruebas. No les importan los cambios internos de desarrollo.

¿Estamos malinterpretando el proceso ágil? ¿Las revisiones de código son incompatibles con un ciclo diario de lanzamiento / prueba? No podemos realizar revisiones de código todos los días, ya que ocupan el tiempo de todos.

gen b.
fuente
Encontré algunas sugerencias que podrían ser útiles: Revisión de código en equipos ágiles, parte II (encontrada en una búsqueda rápida en Google, puede encontrar más).
Dukeling
1
¿Sus evaluadores están trabajando en tareas "liberadas"? ¿La definición de "lanzado" de su equipo incluye la revisión del código y la resolución del elemento de acción? ¿O está ocurriendo la revisión del código fuera de la definición de hecho de su equipo?
Kent A.
1
¿Su equipo de prueba no tiene una suite de regresión automatizada?
Telastyn
55
¿Cómo se hacen las "revisiones de código"? ¿Es este un largo proceso formal en el que los revisores tienen que trabajar a través de una lista de verificación completa de métricas de calidad (esfuerzo: varias horas-persona)? ¿O es simplemente cualquier otro miembro del equipo que mira el código y hace preguntas si algo parece no funcionar (esfuerzo: 10-30 minutos para el codificador y el revisor)? ¿Por qué haces revisiones de código? Para garantizar la calidad del código? Para atrapar insectos? ¿Difundir el conocimiento del sistema entre múltiples personas? ¿Su mecanismo de revisión de código ayuda a cumplir estos objetivos, o es solo burocracia que nadie quiere hacer?
amon
Me gustan todas las respuestas, pero permítanme agregar un punto que considero importante. Pregunta si está malinterpretando Agile, pero no dice qué metodología. ¿Sigues a Scrum? Lo más importante: ¿tiene una definición de "Listo"? Lo pregunto porque me parece muy ... extraño que estés considerando algo "entregado" antes de haber terminado de trabajar en ello. Parece que la revisión de código es algo "extra" que haces solo porque sí.
Lorenzo Dematté

Respuestas:

8

Los probadores no quieren volver a hacer la prueba es como decir "los codificadores no quieren refactorizar". Es parte del trabajo. El proceso puede reiniciarse de la siguiente manera: se crean tareas. Se genera el código. El código está probado. Se revisa el código. Las imperfecciones se encuentran en el código. Se crean nuevas tareas para abordar estas imperfecciones (por ejemplo, el código se refactoriza). Estas nuevas tareas requieren nuevas pruebas.

John
fuente
2
+1 En una metodología Agile de lanzamiento diario, no vuelva a abrir tareas. Cree una nueva tarea para abordar los problemas encontrados y prográmela de acuerdo con las prioridades de su equipo. Nuevas tareas = nueva acción de control de calidad (lo que probablemente significa ejecutar las mismas pruebas nuevamente). Si a QA no le gusta, hay muchas otras carreras.
Kent A.
Eso claramente funciona pero parece ineficiente.
usr
7

Si va a revisar el código en algún momento, no es más costoso hacer la revisión antes de tiempo. Y parece que tiene un proceso de prueba costoso, por lo que no desea realizar la prueba dos veces. Por lo tanto, es más barato revisar el código antes de realizar la prueba. Revisar el código después de la prueba no hace que el trabajo vaya más rápido. Hace que sea más lento y te tienta a entregar código mal escrito pero probado con éxito. Con el tiempo, todo este código no revisado hará que el trabajo vaya más y más lento. Luego, un competidor más eficiente ofrece un mejor producto a menor costo y se acabó el juego.

Además, automatice las pruebas. La prueba manual es tan 1970.

Kevin Cline
fuente
5

Si le resulta difícil realizar revisiones de código en el tiempo que tiene actualmente antes del control de calidad, debería considerar hacer que las revisiones de código sean más livianas, como lo comenta la Revisión de código en Agile Teams, Parte II que publicó @Dukeling.

Descubrí que incluso lo más simple que podría llamarse una revisión de código brindaba beneficios: antes de comprometer el código (o presionar un DVCS), llame a otro desarrollador y guíelos a través de su cambio. Esto puede tomar cinco o diez minutos. El objetivo de esta revisión de código es "¿Tiene sentido para el otro desarrollador?" El objetivo no era criticar las implementaciones de diseño o conformarse completamente con las ideas personales del revisor sobre cómo debería haber sido escrito. Le dio estos beneficios:

  • Mejor conocimiento compartido de cómo funciona el código.
  • Capturó código confuso o potencialmente erróneo porque el acto de explicar el código fue suficiente para que el autor reconsiderara las cosas
  • Ayudó a evolucionar los modismos y el estilo del equipo, porque facilitó la explicación de las cosas.
  • Muy pocas quejas del equipo.

Las revisiones de código más profundas funcionan absolutamente mejor para encontrar problemas. Pero tienes que poder hacerlas y actuar sobre ellas para obtener el valor. Un proceso liviano que puede hacer todo el tiempo puede ser más útil que un proceso pesado que se desanime o simplemente agregue cosas al trabajo atrasado.

Alan Shutko
fuente
1

Una solución para este problema es hacer una revisión rápida del código por parte de otro compañero una vez que la historia del usuario haya finalizado, para que no haya errores básicos / obvios en el código.

Pero esto tiene que suceder antes del ciclo de prueba. Luego, habrá menos cambios de código después de la prueba, cuando realice revisiones más grandes con todo el equipo.

Pelican de bajo vuelo
fuente
1

Por lo que parece, los probadores no quieren volver a probar porque la prueba es un proceso doloroso / costoso.

La automatización de pruebas tanto por parte de desarrolladores como de evaluadores es una gran ventaja para los equipos que intentan trabajar de manera ágil. Cuanto más baratas, fáciles y reproducibles sean sus pruebas, más podrá ejecutarlas y menos resistencia tendrá para cambiar algo.

¿Has hecho un refactor rápido basado en algunos comentarios del desarrollador? Presione el botón rojo grande que ejecuta su paquete de regresión / humo y haga un manual rápido una vez más para verificar si hay problemas visuales que puedan haber surgido. ¡Fácil!

Una vez que esté en un lugar como ese, volver a realizar las pruebas no será una tarea difícil, será una segunda naturaleza.

f1dave
fuente