Revisión avanzada del código y práctica de prueba de unidad

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

¿Cómo va a crear una manera para que la revisión del código y las pruebas unitarias se ajusten naturalmente al flujo del desarrollador?

Una de las resistencias de estas dos áreas es que "siempre estamos ajustados a la fecha, así que no hay tiempo para la revisión del código y las pruebas unitarias".

Otra resistencia para la revisión del código es que actualmente no sabemos cómo hacerlo. ¿Deberíamos revisar el código en cada check-in, o revisar el código en una fecha específica?

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

¿O simplemente intentan rechazar la idea con esta excusa?

En el primer caso, la solución es comenzar a hacerlo ahora . (OK, 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 mío, donde era ingeniero de calidad, responsable de mejorar las prácticas de codificación y calidad general. Seguimos aplazando el inicio de las revisiones de código hasta la próxima semana. Un día me di cuenta de que habíamos estado haciendo esto durante un mes más o menos, y probablemente continuaré hasta el final de los tiempos a menos que intente algo diferente. Así que anuncié la primera revisión de código para esa semana. Les dije a los chicos "no hay problema si será imperfecto, o si aún no sabemos exactamente qué hacer, simplemente comenzaremos a hacerlo, veremos cómo funciona 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 discusión abierta con el equipo. Discutir los problemas de calidad de código, pedirles que lo que ven como problemas en el proceso de desarrollo (o falta de ella) / en el código / pruebas, etc. Y una lluvia de 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 salida. Bien puede resultar que hay otros problemas más dolorosos que podrían mejorarse más fácilmente, trayendo más beneficios más rápido; entonces tome estos primero. Incluso pueden ser cambios triviales en el entorno o el proceso; todo esto mejorará la moral del equipo, generará confianza mutua y ayudará al vínculo del equipo.

La conclusión es que no se puede forzar la calidad sobre nadie, solo se pueden eliminar los obstáculos para crear calidad . Al imponer reglas estrictas y prácticas obligatorias sin el consenso previo del equipo , puede alienar al equipo y, en última instancia, evitar la mejora de la calidad que busca. OTOH, al debatir abiertamente y con el objetivo de llegar a 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.

El clásico problema. Nunca hay tiempo suficiente para hacerlo bien, siempre hay tiempo suficiente para rehacer el trabajo. Hasta que las personas comiencen a hacer las mejores prácticas, nunca parecerá que haya tiempo suficiente para hacer las mejores prácticas. Particularmente porque los triunfos son invisibles para las personas fuera del desarrollo.

La clave para la revisión del código es que desea revisar la menor cantidad de código posible, tan pronto como sea posible. De esta forma, es más fácil tener 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 registro individual. Una buena herramienta para automatizar esto es http://code.google.com/appengine/articles/rietveld.html . Es una variante de la herramienta que Google usa internamente para forzar la revisión del código en cada registro.

El desafío de la revisión del código se describió hace décadas en el clásico The Psychology of Computer Programming . El problema es que los programadores tienden a vincular su propia imagen 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 como algo personal. Esto puede causar serios conflictos. Si elige el desarrollo rápido clásico de Steve McConnell, él le ofrece 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 gerencia nunca participe en el proceso). Tenga en cuenta que esto reduce las probabilidades de conflicto, pero no evita que ocurra un conflicto.

Dicho esto, los beneficios superan con creces los costos. Solo por 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 resulta en muchos, muchos menos problemas para que encuentren. Y eso es antes de obtener beneficios que involucran cuánto acelera el aprendizaje, difunde el conocimiento, etc.

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 probadas o no revisadas. Si las cosas están realmente mal, despide a tu peor delincuente.

He visto casos en los que un equipo siempre está retrasado porque siempre están reparando errores que deberían haber sido detectados por pruebas y revisiones. Un poco más de trabajo por adelantado ahorra mucho más a largo plazo, y cuanto antes alinees a tu equipo, mejor será tu equipo.

Desafortunadamente, esto puede tomar tiempo para ver realmente los resultados. Para alentar la práctica, puede comenzar a trazar la tasa de informes de errores, el tiempo medio para la corrección de errores y la tasa de implementación de características. Por lo general, encuentro que después de aproximadamente seis meses de pruebas y revisiones, esas métricas mejorarán y su equipo finalmente lo obtendrá.

Introducir tdd contra la voluntad de los desarrolladores es difícil. Es una forma difícil de aprender a amar el tdd.

Dado que tdd es más eficiente en un campo verde (o difícil, costoso e ineficiente si las pruebas se llevan a cabo después), comenzaría con un pequeño equipo que implementa algo nuevo. Si encuentra dos desarrolladores en el equipo que son menos opuestos a tdd que los otros, ese 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 revisión de código. Discuta cómo el tdd influyó en la arquitectura del programa y cómo facilita el mantenimiento del software.