Avance de la revisión de códigos y la práctica de pruebas unitarias

15

Como líder de equipo que administra un grupo de desarrolladores sin experiencia (y no ve necesidad) en la revisión de códigos y pruebas de unidad, ¿cómo puede avanzar en la práctica de revisión de códigos y pruebas de unidades?

¿Cómo va a crear una manera para que la revisión del código y las pruebas de unidad encajen naturalmente en el flujo del desarrollador?

Una de las resistencias de estas dos áreas es que "siempre estamos ajustados a la línea de datos, por lo que no tenemos tiempo para revisar el código y realizar pruebas de unidad".

Otra resistencia para la revisión del código es que actualmente no sabemos cómo hacerlo. ¿Debemos revisar el código en cada registro o revisar el código en una fecha específica?

    
pregunta Graviton 11.02.2011 - 07:25
fuente

4 respuestas

16

¿Los miembros de su equipo realmente están de acuerdo en que las revisiones de códigos y las pruebas de unidad son cosas buenas, solo que no hay tiempo para estas?

¿O simplemente intentan rechazar la idea con esta excusa?

En el primer caso, la solución es Comenzar a hacerlo ahora . (De acuerdo, si está en los últimos días antes de un hito importante, tal vez pueda esperar hasta después, pero no más.) Tuvimos esa situación en un lugar de trabajo anterior en el que yo era Ingeniero de Calidad, responsable de mejorar las prácticas de codificación y calidad general. Continuamos aplazando el inicio de las revisiones de códigos hasta la próxima semana. Un día me di cuenta de que hemos estado haciendo esto durante aproximadamente un mes, y probablemente continuará hasta el final de los tiempos, a menos que intente algo diferente. Así que anuncié la primera revisión del código para esa semana. Les dije a los muchachos "no hay problema si será imperfecto, o si no sabemos exactamente qué hacer todavía, simplemente comenzaremos a hacerlo, veremos cómo va y mejoraremos las cosas a medida que aprendemos". Funcionó, al menos hasta que dejé la empresa.

En el segundo caso, es posible que necesite más educación y una discusión abierta con el equipo. Discuta los problemas de calidad del código, pregúnteles qué ellos ven como problemas en el proceso de desarrollo (o la falta de ellos) / en el código / prueba, etc. Y intercambian ideas acerca de cómo resolver estos . El objetivo final no es necesariamente hacer revisiones de código, son solo medios, mientras que el objetivo es mejorar el proceso de desarrollo y la calidad de su producción. Es posible que resulte que hay otros problemas más dolorosos que podrían mejorarse más fácilmente y traer más beneficios más rápido; entonces toma estos primero Incluso pueden ser cambios triviales en el entorno o en el proceso; todo esto mejorará la moral del equipo, generará confianza mutua y ayudará al vínculo del equipo.

La conclusión es, no puede imponer la calidad a nadie, solo puede eliminar los obstáculos para crear calidad . Al hacer cumplir las reglas estrictas y las prácticas obligatorias sin un consenso previo del equipo , puede alienar al equipo y, en última instancia, evitar la mejora de la calidad que busca. OTOH, a través de una discusión abierta y buscando un acuerdo sobre cuáles son los problemas más apremiantes para el equipo y cómo mejorar la situación, es más probable que obtenga apoyo del equipo. Esto marcará una diferencia crucial para mantener el impulso de mejora de la calidad a largo plazo.

    
respondido por el Péter Török 11.02.2011 - 09:24
fuente
5

El problema clásico. Nunca el tiempo suficiente para hacerlo bien, siempre el tiempo suficiente para rehacer el trabajo. Hasta que las personas empiecen a hacer las mejores prácticas, nunca habrá tiempo suficiente para hacer las mejores prácticas. Particularmente porque las ganancias son invisibles para las personas fuera del desarrollo.

La clave para la revisión del código es que desea revisar el menor código posible lo más inmediato posible. De esa manera, es más fácil obtener el tiempo para revisarlo, el código está fresco en la mente de las personas y la implementación de las mejoras sugeridas será más fácil. En el extremo desea revisar cada check-in individual. Una buena herramienta para automatizar esto es enlace . Es una variante de la herramienta que Google usa internamente para forzar la revisión del código para que ocurra con cada registro.

El desafío de la revisión de código se describió hace décadas en el clásico La psicología de la programación informática . El problema es que los programadores tienden a vincular su autoimagen con sus habilidades de programación. Lo que significa que cada vez que los programadores se enfrentan a la evidencia de que sus habilidades no están a la altura, hay una tendencia a tomarlo personalmente. Esto puede causar serios conflictos. Si selecciona el clásico Rapid Development de Steve McConnell, le ofrecerá una serie de sugerencias sobre cómo configurar un proceso de revisión de código que reduzca las probabilidades de tal conflicto. (Un elemento clave es asegurarse de que la administración nunca participe en el proceso). Tenga en cuenta que esto reduce las probabilidades de conflicto, pero no evita que ocurra el conflicto.

Dicho esto, los beneficios superan con creces los costos. Solo para citar una métrica, IBM descubrió que la revisión del código era dólar por dólar, la forma más efectiva de encontrar y eliminar errores. Esto no reemplaza su departamento de control de calidad de ninguna manera. Pero da como resultado muchos menos problemas para que los encuentren. Y eso es antes de que entre en los beneficios que implican cuánto acelera el aprendizaje, difunde el conocimiento, etc.

    
respondido por el btilly 11.02.2011 - 08:57
fuente
3

No les des la opción. Hacer pruebas y revisiones obligatorias. Si no cooperan, puede recurrir a algunas tácticas de línea dura, como rechazar promociones no verificadas o no revisadas. Si las cosas están realmente mal, despida a tu peor ofensor.

He visto casos en los que un equipo siempre está retrasado porque siempre están solucionando errores que deberían haberse detectado mediante pruebas y revisiones. Un poco más de trabajo por adelantado ahorra mucho más a largo plazo, y cuanto antes ponga a su equipo en la fila, mejor se pondrá su equipo.

Lamentablemente, esto puede llevar tiempo para ver realmente los resultados. Para alentar la práctica, puede comenzar a registrar la tasa de informes de errores, el tiempo medio para corregir las fallas y la tasa de implementación de funciones. Por lo general, encuentro que después de seis meses de pruebas y revisiones, esas métricas mejorarán y su equipo finalmente las obtendrá.

    
respondido por el smithco 11.02.2011 - 08:42
fuente
1

La introducción de tdd en contra de la voluntad de los desarrolladores es difícil. Es una manera difícil de aprender a amar tdd.

Dado que tdd es más eficiente en un campo verde (o difícil, costoso, ineficiente si las pruebas se ejecutan después de todo), comenzaría con un equipo pequeño que implementa algo nuevo. Si encuentra dos develloppers en el equipo que son menos opuestos a tdd que los demás, es un buen punto de partida. tenga en cuenta que la productividad de los desarrolladores de tdd sufrirá mientras no tengan experiencia con tdd.

Este desarrollo de tdd es un buen punto de partida para una vista de código. Discuta cómo influyó el tdd en la arquitectura del programa y cómo facilita el mantenimiento del software.

    
respondido por el k3b 11.02.2011 - 09:27
fuente

Lea otras preguntas en las etiquetas