¿Cómo determinar la efectividad de un proceso de revisión de código?

Hemos introducido un proceso de revisión de código dentro de nuestra organización y parece estar funcionando bien. Sin embargo, me gustaría poder medir la efectividad del proceso a lo largo del tiempo, es decir, ¿no estamos encontrando errores porque el código está limpio o las personas simplemente no están detectando errores?

Actualmente, no tenemos un proceso de prueba totalmente automatizado y efectivo. Principalmente empleamos pruebas manuales, por lo que no podemos confiar en los defectos encontrados en esta etapa para garantizar que el proceso de revisión del código esté funcionando.

¿Alguien se ha encontrado con este problema antes o tiene alguna idea sobre lo que funciona bien en las revisiones de códigos de medición?

Hay una serie de métricas que se pueden recopilar de las revisiones de código, algunas incluso se extienden a lo largo del ciclo de vida del proyecto.

La primera métrica que recomendaría recopilar es la efectividad de eliminación de defectos (DRE) . Para cada defecto, identifica en qué fase se introdujo el defecto y en qué fase se eliminó. Las diversas técnicas de detección de defectos que utiliza se evalúan todas simultáneamente, por lo que se aplica igualmente a las revisiones de requisitos, revisiones de diseño, revisiones de códigos, pruebas unitarias , y así. Usted estaría particularmente interesado en la cantidad de defectos atrapados en la fase del código, ya que esto probablemente abarcaría las pruebas de su unidad, así como las revisiones del código. Si muchos defectos de la fase de código están llegando a la fase de prueba de integración o incluso al campo, sabrá que debe evaluar las prácticas posteriores a la codificación.

Varias métricas de la reunión también serían relevantes. Estos incluyen el tiempo de preparación, el tiempo de reunión, las líneas de lectura de códigos, los defectos encontrados en la revisión, etc. Se pueden hacer algunas observaciones a partir de estos datos. Como ejemplo sería si sus revisores pasan una gran cantidad de tiempo leyendo el código en preparación para la revisión, pero encuentran muy pocos problemas. Junto con los datos DRE, puede llegar a la conclusión de que si los defectos se prueban en las pruebas de integración o en el campo, entonces su equipo debe centrarse en sus técnicas de revisión para poder encontrar problemas. Otra nota interesante sería las líneas de código (o alguna otra medida de tamaño) leídas en una reunión en comparación con la hora de la reunión. La investigación ha encontrado que la velocidad de una revisión de código típica es de 150 líneas de código por hora.

Con cualquiera de estas métricas, es importante comprender su impacto en el proceso. Análisis de causa raíz, utilizando técnicas tales como por qué, porque , Cinco porqués , o diagramas de Ishikawa se pueden utilizar para identificar las razones por las revisiones de código (o cualquier otra técnica de mejora de la calidad) son (en) eficaz.

También podría estar interesado en este artículo sobre inspecciones de The Ganssle Group y un artículo de Capers Jones en Crosstalk sobre Defect Potentials y DRE .

Si bien en gran medida es cierto que la revisión de código detectaría problemas que están bastante latentes y que las pruebas pueden o no detectarse. Sin embargo, en mi opinión, es posible que tenga un código realmente estable (prácticamente libre de errores) pero aún así escrito de tal manera que sea extremadamente no legible o no del todo mantenible. Por lo tanto, puede ser que la revisión del código NO encuentre errores si no hay problemas reales en el código.

Habiendo dicho eso, realmente preguntaría, ¿por qué querría hacer una revisión de código? La razón simple por la que es importante es que el código debe mejorarse para que sea más legible, mantenible y evolutivo. Muchas personas deberían poder leer códigos más limpios y tener sentido. En ese sentido, el objetivo más simple del proceso de revisión de código es producir código limpio. Entonces, la medida de la eficacia es cuánto más limpio es el código ahora.

Como quería tener una efectividad medible, esto es lo que sugeriría:

1. Métrica relacionada con la cantidad de retrabajo: el número de veces que el retrabajo se aplica en un mismo módulo / objeto / elemento de trabajo dado es una medida de cuán pobre es ese código en términos de mantenibilidad. Cuando se aplica una revisión de código efectiva, ¿con qué frecuencia podemos reducir la solicitud de reelaboración en el mismo módulo?

2. Métrica relacionada con la cantidad de cambio en que incurre cada solicitud de cambio. Cuando se produce una solicitud de cambio, un código mal factorizado siempre tendrá un mayor número de módulos afectados. Una medida probablemente indicaría que, después de una revisión del código, ¿hubo alguna reducción de tal extensión de cambio para una solicitud de cambio similar en el pasado?

3. Métrica relacionada con la velocidad promedio con la que se puede responder una solicitud de cambio. Cuando el código es más limpio, más rápido y mejor es responder a los cambios requeridos. Después de que se limpió el código en el proceso de revisión, vemos que se acelera la respuesta a una solicitud de tamaño similar.

No estoy poniendo unidades exactas de medidas, probablemente puede elaborar medidas más precisas sobre esto desde este enfoque. Puede haber más formalismo de extensión en los enfoques anteriores sobre esto.

Básicamente, mi punto es que en lugar de mirar la cantidad de errores que identifica el proceso de revisión de código; debemos medir la efectividad en términos de si la revisión de código ha sido capaz de hacer que el código sea más limpio, más ágil y más fácil de mantener; por lo tanto, podemos medir esa efectividad si vemos que solicitudes de cambio similares en el futuro se vuelven más eficientes para ser respondidas.