¿Métricas del código fuente para medir la estabilidad del código?

17

Teniendo en cuenta cómo se desarrolla el software durante un ciclo de lanzamiento (implementación, prueba, corrección de errores, lanzamiento), estaba pensando que uno debería poder ver algún patrón en las líneas de código que se cambian en la base del código; por ejemplo, hacia el final de un proyecto, si el código se vuelve más estable, uno debería ver que se modifican menos líneas de código por unidad de tiempo.

Por ejemplo, uno podría ver que durante los primeros seis meses del proyecto, el promedio fue de 200 líneas de código por día, mientras que durante el último mes fue de 50 líneas de código por día, y durante la última semana (justo antes de los DVD del producto fueron enviados), no se cambió ninguna línea de código (congelación de código). Esto es solo un ejemplo, y podrían surgir diferentes patrones de acuerdo con el proceso de desarrollo adoptado por un equipo en particular.

De todos modos, ¿hay alguna métrica de código (alguna literatura sobre ellas?) Que use el número de líneas de código modificadas por unidad de tiempo para medir la estabilidad de una base de código? ¿Son útiles para tener una idea de si un proyecto está llegando a algún lado o si aún está lejos de estar listo para lanzarse? ¿Hay alguna herramienta que pueda extraer esta información de un sistema de control de versiones y producir estadísticas?

code-metrics

— Giorgio
fuente

1

ndepend.com/Features.aspx#BuildComparison

— AakashM

44

"En segundo lugar, el mecanismo es abstracto, su producción está incluida en su diseño. A este respecto, un programa es como un poema: no se puede escribir un poema sin escribirlo. Sin embargo, la gente habla de la programación como si fuera un proceso de producción y una medida". productividad del programador "en términos de" número de líneas de código producidas ". Al hacerlo, reservan ese número en el lado equivocado del libro mayor: siempre debemos referirnos a" el número de líneas de código gastadas ". - Los frutos del malentendido , Edsger W. Dijkstra.

— Yannis

3

@ Yannis Rizos: de ninguna manera estoy sugiriendo medir la productividad o la complejidad del código por LOC porque sé que esta no es una buena medida. Por otro lado, si se cambiaran 300 líneas de código dos días antes del envío, yo como gerente tendría una gran luz de "ALERTA ROJA" en mi mente (a menos que esto haya sido planeado y sea el resultado de una evaluación muy cuidadosa de los riesgos ) En general, supongo que el código que se ha utilizado (y probado) sin haber sido modificado durante mucho tiempo es "más estable" que el código en el que se cambian 100 líneas todos los días.

— Giorgio

2

@Giorgio Argh, fui interrumpido (a mitad de la jornada laboral aquí) mientras publicaba otro comentario (alcanzó el límite de char en el primero). No quería decir que estaba hablando de productividad, la cita de Dijkstra se me ocurrió y pensé que sería interesante. En cualquier caso, las métricas de cambio de código se acercan bastante a lo que está buscando, y hay toneladas de literatura sobre ellas. En cuanto a las herramientas, Atlassian's FishEye es espectacular.

— yannis

@ Yannis Rizos: De hecho, es una lectura muy interesante. En cuanto a FishEye, lo usamos en nuestro lugar de trabajo (para revisiones), por lo que consultaré inmediatamente el manual y veré qué tipo de estadísticas podemos producir.

— Giorgio

17

Una medida que Michael Feather ha descrito es " El conjunto activo de clases ".

Mide el número de clases agregadas contra las "cerradas". El cierre de clase se describe como:

Se cierra una clase en la fecha en que no se le realizan más modificaciones desde esa fecha hasta el presente.

Utiliza estas medidas para crear gráficos como este: Gráfico de clase activa

Cuanto menor sea el espacio entre las dos líneas, mejor.

Es posible que pueda aplicar una medida similar a su base de código. Es probable que el número de clases se correlacione con el número de líneas de código. Incluso puede ser posible extender esto para incorporar una línea de código por medida de clase, que podría cambiar la forma del gráfico si tiene algunas clases monolíticas grandes.

— Dave Hillier
fuente

4

Siempre que haya un mapeo relativamente consistente de características para las clases, o para el caso, el sistema de archivos podría conectar algo como gource en su sistema de control de versiones y muy rápidamente tener una idea de dónde se centra la mayor parte del desarrollo (y por lo tanto qué partes del código son las más inestables).

Esto supone que tiene una base de código relativamente ordenada. Si la base del código es una bola de lodo, esencialmente verá cada pequeña porción en la que se trabaja debido a las interdependencias. Dicho esto, tal vez eso en sí mismo (la agrupación mientras se trabaja en una función) es una buena indicación de la calidad de la base del código.

También supone que su negocio y su equipo de desarrollo en su conjunto tienen alguna forma de separar las características en el desarrollo (ya sea en el control de versiones, una característica a la vez, lo que sea). Si, por ejemplo, está trabajando en 3 características principales en la misma rama, entonces este método produce resultados sin sentido, porque tiene un problema mayor que la estabilidad del código en sus manos.

Desafortunadamente, no tengo literatura para probar mi punto. Se basa únicamente en mi experiencia de usar gource en bases de código buenas (y no tan buenas).

Si está utilizando git o svn y su versión de gource es> = 0.39, es tan simple como ejecutar gource en la carpeta del proyecto.

— Carl
fuente

¡gource también parece ser una gran herramienta! (+1)

— Giorgio

1

Me topé con esta respuesta, luego pasé las siguientes seis horas jugando con Gource. No estoy seguro de si eso merece un +1 o un -1, pero maldita sea, esa es una herramienta genial.

— RonU

@RonU: puede usar gource para visualizar el estado del repositorio en un rango de tiempo personalizado. El punto es que visualiza la actividad en su base de código a lo largo del tiempo. La facilidad de interpretación de la información depende de muchos factores, como he explicado en mi respuesta anterior. Sí, es una herramienta increíble si quieres el "panorama general", así que creo que merece un +1;)

— Carl

Sí, cuando dije "seis horas", no quise decir que ejecuté un simulador de Gource para ese momento ... solo que jugué con muchas opciones, lo conecté a ffmpeg, posiblemente agregué una banda sonora épica, etc. Era bastante la madriguera del conejo. :)

— RonU

Déjame adivinar. La banda sonora fue el Harlem Shuffle en bucle;)

— Carl

0

El uso de la frecuencia de las líneas modificadas como indicador de la estabilidad del código es al menos cuestionable.

Al principio, la distribución en el tiempo de las líneas modificadas depende en gran medida del modelo de gestión de software del proyecto. Existen grandes diferencias en los diferentes modelos de gestión.

En segundo lugar, la víctima en esta suposición no está clara: es el recuento más bajo de líneas modificadas causado por la estabilidad del software, o simplemente porque la fecha límite expira y los desarrolladores decidieron no hacer algunos cambios ahora, sino hacerlo después de la ¿lanzamiento?

En tercer lugar, la mayoría de las líneas se modifican cuando se introducen nuevas características. Pero la nueva característica no hace que el código no sea estable. Depende de la habilidad del desarrollador y de la calidad del diseño. Por otro lado, incluso los errores graves pueden corregirse con muy pocos cambios de línea; en este caso, la estabilidad del software aumenta significativamente, pero el recuento de líneas cambiadas no es demasiado grande.

— johnfound
fuente

"Depende de la habilidad del desarrollador y de la calidad del diseño". Pero necesita al menos algo de tiempo para probar los cambios y tener la confianza suficiente de que no ha introducido ningún error. Incluso los desarrolladores más hábiles pueden cometer errores de mecanografía, por ejemplo, si están bajo presión, han hecho demasiadas horas extra o han dormido muy poco. Además, si aplica el principio de abrir / cerrar, después de un tiempo la cantidad de cambios (correcciones de errores) debería disminuir. De todos modos, he declarado explícitamente en mi pregunta que el resultado de tal medición puede cambiar de acuerdo con el proceso de desarrollo.

— Giorgio

Por cierto, el código puede ser inestable no porque los desarrolladores sean malos, sino porque los requisitos no son claros y el proyecto todavía está en una fase de creación de prototipos.

— Giorgio

@ Jorge: Por supuesto que tienes razón. Pero esto es exactamente lo que escribí: el recuento de líneas modificadas depende en gran medida de demasiados factores. Algunos de ellos relacionados con la estabilidad del código, otros no. Es como tratar de calcular cuántas personas tienen relaciones sexuales, midiendo la potencia eléctrica, suponiendo, menos potencia, menos luces, más sexo. Aunque está comprobado que la tasa de natalidad aumenta después de grandes apagones. ;)

— johnfound

-1

Robustez es un término relacionado con la función correcta de un conjunto de instrucciones, no con la cantidad, la verbosidad, la concisión, la corrección gramatical del texto utilizado para expresar esas instrucciones.

De hecho, la sintaxis es importante y debe ser correcta, pero cualquier cosa más allá de eso, ya que se refiere a la función deseada de las instrucciones al observar las 'métricas' de las instrucciones, es similar a trazar su futuro leyendo el patrón de hojas de té en la parte inferior de tu taza de te

La robustez se mide mediante pruebas. Pruebas unitarias, pruebas de humo, pruebas de regresión automatizadas; pruebas, pruebas, pruebas!

Mi respuesta a su pregunta es que está utilizando un enfoque incorrecto al buscar una respuesta a una de solidez. Es una pista falsa que las líneas de código significan algo más que líneas que ocupan código. Solo puede saber si el código hace lo que quiere que haga si prueba que está haciendo lo que necesita.

Vuelva a visitar los arneses de prueba adecuados y evite el misticismo de código métrico.

Los mejores deseos.

— Sassafras_wot
fuente

3

He declarado explícitamente que no estaba sugiriendo LoC como una medida de la complejidad del código. Estaba sugiriendo los cambios en el código como una medida de la estabilidad del código: ¿un código tiene requisitos funcionales estables y una implementación estable y probada que cumpla con esos requisitos?

— Giorgio

No quiero discutir contigo, sino respetuosamente guiarte lejos de la locura de la falta de sentido de la métrica del código. Volví a leer su pregunta y todos sus ejemplos indican un deseo de inferir una relación entre las líneas de código que cambian y la robustez resultante de las mismas. Entiendo que cuantas más palabras escriba, más probabilidades tendrá de hacer un error tipográfico. Pero estoy tan en contra del principio en lo que me pides que debo salir firmemente a favor de que abandones tu búsqueda de esta manera. Buenas prácticas de prueba = buena probabilidad de robustez.

— Sassafras_wot

"Buenas prácticas de prueba = buena probabilidad de robustez": estoy totalmente de acuerdo. Es por eso que estoy sugiriendo que una pieza de código que se ha cambiado recientemente debe probarse nuevamente antes de que podamos estar seguros de que es correcta.

— Giorgio

Hay varias definiciones de estabilidad y una de ellas es por lo que estás argumentando. Es una interpretación semántica diferente a la que hice. Tomé estable para decir que "no está sujeto a cambios extremos" en lugar de "resistente al cambio"

— Dave Hillier