¿Cuáles son las métricas útiles para el código fuente? [cerrado]

¿Cuáles son las métricas útiles para capturar para el código fuente?

¿Cómo pueden las métricas, como por ejemplo (Ejecutable?) Líneas de Código o Complejidad Ciclomática ayudar con el aseguramiento de la calidad o cómo son beneficiosas en general para el proceso de desarrollo de software?

"Medir la productividad del software por líneas de código es como medir el progreso en un avión por cuánto pesa" - Bill Gates

Echa un vistazo a las publicaciones de Jeff sobre el tema:

Una visita de Metrics Maid

Ingeniería de software: ¿muerto?

También hay una publicación antigua, pero buena, de Joel, estrechamente relacionada con las métricas de software, y recomiendo encarecidamente su lectura: El método de gestión Econ 101

El punto clave, para mí, es este, citando a Jeff: "El uso responsable de las métricas es tan importante como recopilarlas en primer lugar".

Lo que me confunde acerca de las métricas de código es que no se hace más. La mayoría de las compañías informan sobre la eficiencia de sus empleados, proveedores y sistemas establecidos, pero nadie parece querer informar sobre el código. Definitivamente voy a estar de acuerdo con las respuestas que afirman que más líneas de código es una responsabilidad, pero lo que hace su código es más importante.

Líneas de código: como he mencionado, esta es una medida vital y debe tomarse con la mayor seriedad, pero en cada nivel. Las funciones, clases, archivos e interfaces pueden indicar código de hacer todo que es difícil de mantener y costoso a largo plazo. Es infinitamente difícil comparar las líneas totales de código versus lo que hace un sistema. ¡Podría ser algo que haga muchas cosas y en ese caso habrá muchas líneas de código!

Complejidad: esta medición es buena para hacer en bases de código en las que no ha trabajado, y puede darle una buena indicación de dónde se encuentran las áreas problemáticas. Como anécdota útil, medí la complejidad en una de mis propias bases de código, y el área de mayor complejidad fue la que más tiempo pasé cuando necesitaba cambiarla. Trabajar para reducir la complejidad resultó en una reducción masiva en el tiempo de mantenimiento. Si la gerencia tuviera estas medidas a mano, podrían planificar iteraciones de refactorización o rediseños de áreas específicas de un sistema.

Duplicación de código: esta es una medida muy importante en lo que a mí respecta. La duplicación de código es una muy mala señal y podría señalar problemas profundos en los niveles bajos del diseño de un sistema o desarrolladores que copian y pegan, causando problemas masivos a largo plazo y sistemas que no se pueden mantener.

Gráficos de dependencia Encontrar malas dependencias y dependencias circulares es una medida importante en el código. Esto casi siempre apunta a un diseño incorrecto de alto nivel que necesita revisión. A veces, una dependencia puede absorber muchas otras innecesarias, porque alguien está usando addNumber dentro de una biblioteca de correo electrónico para hacer sus cálculos financieros. Todos se sorprenden cuando se cambia la biblioteca de correo electrónico y se interrumpe la financiación. Si todo depende de una cosa, también puede apuntar a hacer todo, bibliotecas que son difíciles de mantener y están mal diseñadas.

Una buena medición siempre le dirá que cada característica de un sistema tiene una huella pequeña. Menos dependencias, menos complejidades, menos duplicación. Esto apunta a acoplamiento flojo y alta cohesión.

¿Acaso esta "métrica del código fuente" nunca morirá?

Las líneas de código fuente sin formato (SLOC) son la métrica más antigua, fácil y básica que existe.

Halstead propuso originalmente un montón de métricas. Mucha gente se estaba divirtiendo mucho escribiendo programas de medición hasta que algunos deportes de base hicieron el estudio obvio y demostraron que todas y cada una de las métricas de Halstead estaban estrechamente relacionadas directamente con SLOC.

En ese momento, las métricas de Halstead fueron abandonadas, porque SLOC siempre es más fácil de medir.

Las métricas del código fuente para el aseguramiento de la calidad apuntan a dos objetivos:

• escribir código con menos errores dentro
• escribir código para facilitar el mantenimiento

Ambos conducen a escribir código lo más simple posible. Esto significa:

• unidades cortas de código (funciones, métodos)
• pocos elementos en cada unidad (argumentos, variables locales, declaraciones, rutas)
• y muchos otros criterios más o menos complejos (ver Métrica del software en Wikipedia).

Que yo sepa, el número de errores encontrados se correlaciona directamente con líneas de código (probablemente abandono), lenguaje de módulo, programador y dominio.

No conozco ninguna otra métrica directa y práctica que esté bien correlacionada con los errores.

Una cosa que me gustaría hacer es comenzar a ejecutar los números para los diferentes proyectos en los que estoy trabajando: Cobertura de prueba :: kLOC, y luego discutir la "calidad percibida" para ver si hay una correlación.

Las métricas solo son útiles si sabe qué hacer con las respuestas que obtiene. En esencia, una métrica de software es como un termómetro. El hecho de que midas algo a 98.6 ° F no significa nada hasta que sepas cuál es la temperatura normal . La temperatura anterior es buena para la temperatura corporal pero realmente mala para el helado.

Las métricas comunes que pueden ser útiles son:

• Errores descubiertos / semana
• Errores resueltos / semana
• # Requisitos definidos / liberación
• # Requisitos implementados / lanzamiento

Las dos primeras tendencias de medida. ¿Encuentra errores más rápido de lo que puede solucionarlos? Dos posibles resultados: tal vez necesitemos más recursos para corregir errores, tal vez necesitemos dejar de implementar nuevas funciones hasta que nos pongamos al día. Los segundos dos proporcionan una imagen de lo cerca que está de haber terminado. Los equipos ágiles lo llaman una tabla de "quemar".

La complejidad ciclomática es una métrica interesante. En su concepto base, es el número de rutas de ejecución únicas en una función / método. En un entorno pesado de pruebas unitarias, esto corresponde al número de pruebas necesarias para verificar cada ruta de ejecución. Sin embargo, el hecho de que tenga un método que tenga una Complejidad Ciclomática de 96 no significa que sea necesariamente un código defectuoso, o que tenga que escribir 96 pruebas para proporcionar una confianza razonable. No es raro que el código generado (a través de WPF o generadores de analizadores) cree algo tan complejo. Puede proporcionar una idea aproximada del nivel de esfuerzo necesario para depurar un método.

Línea de fondo

Cada medida que tome debe tener lo siguiente definido o es inútil:

• Una comprensión de lo que es "normal". Esto se puede ajustar durante la vida del proyecto.
• Un umbral fuera de "normal" donde necesita tomar algún tipo de acción.
• Un plan para tratar con el código cuando se supera el umbral.

Las métricas que tome pueden variar ampliamente de un proyecto a otro. Es posible que tenga algunas métricas que utilice en todos los proyectos, pero la definición de "normal" será diferente. Por ejemplo, si un proyecto descubrió un promedio de 5 errores / semana y el nuevo proyecto está descubriendo 10 errores / semana, no necesariamente significa que algo está mal. Es posible que esta vez el equipo de pruebas sea más meticuloso. Además, la definición de "normal" puede cambiar durante la vida del proyecto.

La métrica es solo un termómetro, lo que hagas depende de ti.

El código fuente es un pasivo, no un activo. Con eso en mente, medir líneas de código es análogo al seguimiento de los dólares gastados mientras se construye una casa. Debe hacerse si desea mantenerse por debajo del presupuesto, pero no necesariamente pensaría que gastar $ 1000 por día es mejor que gastar $ 50 por día; te gustaría saber cuánto de la casa se construyó con ese dinero. Es lo mismo con las líneas de código en un proyecto de software.

En resumen, no hay métricas útiles para el código fuente porque medir el código fuente por sí solo no es útil.

Dado que el código fuente es simplemente una combinación de secuencia, selección y repetición. Si tuviera que describir la pieza de software más óptima que razonablemente podríamos esperar producir, sería la siguiente. Software con una cobertura de código de prueba de casi el 100% que utiliza la menor cantidad de líneas de código necesarias para hacer el trabajo y, sin embargo, lo suficientemente flexible como para soportar los cambios.

Una anécdota para mostrar por qué los recuentos de KLOC son inútiles (e incluso perjudiciales) para medir el rendimiento.

Hace años trabajé en un gran proyecto (más de 70 personas en nuestra empresa, más de 30 en nuestro cliente) que usaba KLOC como la única medida del desempeño de equipos e individuos.

Para nuestro esfuerzo Y2K (le dice cuánto tiempo hace que era :)) hicimos una gran limpieza de la sección del código de la que era responsable mi equipo. Terminamos para el lanzamiento escribiendo alrededor de 30,000 líneas de código, no fueron malos 3 meses de trabajo para 5 personas. También terminamos desechando otras 70,000 líneas de código, un muy buen trabajo por 3 meses de trabajo, especialmente combinado con el nuevo código.

Resultado final del trimestre: -40,000 líneas de código. Durante la evaluación del desempeño posterior al trimestre, recibimos una reprimenda oficial de la compañía por no cumplir con nuestros requisitos de productividad de 20,000 líneas de código producidas por trimestre (después de todo, las herramientas mostraron que habíamos producido -40,000 líneas de código), que habría resultado en que todos estuviéramos en la lista de bajo desempeño y pasados ​​por alto para promociones, capacitación, aumento de sueldo, etc.

Unos meses más tarde (estas cosas llevan tiempo) nos dijeron que la compañía estaba revisando sus estándares de productividad y había contratado a un equipo de expertos para crear un nuevo sistema basado en el análisis de puntos de función.

Me sorprende que nadie haya mencionado la Declaración / Cobertura de decisión de las pruebas unitarias (porcentaje del código ejercido por las pruebas unitarias) todavía.

La cobertura del código es útil porque sabe qué porcentaje de la aplicación no falla catastróficamente; con el resto de su utilidad depende de la calidad de las pruebas unitarias.

Cuanto más pequeño es el commit, mejor, por lo general. Se trata de herramientas SCM, no de código per se, pero es una métrica muy medible. Cuanto más pequeño sea el compromiso, más fácil será ver cada cambio como una unidad atómica; cuanto más fácil es revertir cambios específicos y precisar cuando las cosas se rompen.

Mientras ningún commit rompa la compilación ...

Estas no son métricas absolutas muy útiles en términos de progreso, pero pueden usarse para dar una idea general del estado del código.

En particular, la Complejidad Ciclomática que he encontrado útil en términos de visualizar cuán modularizada es una base de código dada. En general, desea una baja complejidad ya que esto significa que el número de fuentes por módulo es bajo y hay muchos módulos.

A menudo trabajo en un paquete gigante de C ++, y cuando busco un código problemático que valga la pena refactorizar la Complejidad Ciclomática o el horrible FanIn / FanOut , generalmente son buenas señales de alerta para buscar. Solucionar problemas allí generalmente conducirá a mejoras en toda la base de código.

Por supuesto, estos números solo pueden servir como una pista sobre lo que valdría la pena mirar. Hacer que este sea un umbral difícil después del cual fallar una construcción o rechazar una confirmación sería ridículo.

Hay muchas situaciones en mi trabajo donde uso métricas de código:

Mientras escribe código

El uso más grande y quizás más importante en mi trabajo diario es Checkstyle , una herramienta para desarrolladores de Java que verifica continuamente las métricas (entre otras cosas) de mi código contra un conjunto de reglas que hemos definido y marca lugares donde mi código no cumplir con esas reglas. A medida que desarrollo el código, me dice en tiempo real si mis métodos se vuelven demasiado largos, complejos o acoplados, lo que me permite dar un paso atrás y pensar en refactorizarlo a algo mejor.

Los desarrolladores son completamente libres de romper todas las reglas ya que nunca se aplicarán a todas las situaciones. Las "reglas" están ahí para estimular el pensamiento y decir "Oye, ¿es esta la mejor manera de hacer esto?"

Durante el control de calidad / revisiones de código

Lo primero que hago generalmente cuando realizo una revisión de código es verificar la cobertura de código del código que estoy revisando junto con una herramienta de cobertura de código que resalta qué líneas de código se han cubierto. Esto me da una idea general de cuán exhaustivo es el código de prueba. Realmente no me importa si la cobertura es del 20% o 100%, siempre que el código importante esté bien probado. Por lo tanto, el porcentaje cubierto no tiene sentido, pero el 0% seguro se destaca como un pulgar dolorido como algo que quiero mirar con cuidado.

También verifico qué métricas acordadas por el equipo se han "roto", si las hay, para ver si estoy de acuerdo con el desarrollador en que estaba bien o si puedo sugerir formas de mejorarlo. Tener estas métricas de desarrollo acordadas en nuestro equipo para escribir código nuevo ha hecho grandes avances para mejorar nuestro código. Escribimos mucho menos métodos monolíticos y ahora somos mucho mejores en el principio de responsabilidad única .

Mejoras de tendencia en el código heredado Tenemos muchos códigos heredados que nos gustaría mejorar. Las métricas en cualquier momento son bastante inútiles, pero lo importante para nosotros es que con el tiempo la cobertura del código aumenta y cosas como la complejidad y el acoplamiento disminuyen. Por lo tanto, nuestras métricas están conectadas a nuestro servidor de Integración Continua, lo que nos permite mirar con el tiempo para asegurarnos de que estamos en el camino correcto.

Familiarizarse con una nueva base de código La única vez que uso líneas de métrica de código fuente es cuando busco una base de código con la que no estoy familiarizado. Me permite medir rápidamente el tamaño aproximado del proyecto en comparación con otros con los que he trabajado. Usando otras métricas también puedo obtener una idea aproximada de la calidad del proyecto.

Las cosas clave son usar métricas como puntos de partida para tendencias, discusiones o formas de avanzar y no manejarlas religiosamente para obtener cifras exactas. Pero sí creo firmemente que pueden ayudarlo a mejorar el código correcto cuando se usa correctamente.

P: ¿Cuáles son las métricas útiles para capturar para el código fuente?

Para los negocios:

A: número de horas hombre

Para el supervisor del codificador:

A: no importa. Hagamos todo hoy

Para la autoestima del codificador:

A: Número de SLOC (líneas de código fuente)

Para la madre del codificador:

R: Come más de estos panecillos franceses suaves y bebe té

continúa en los comentarios a continuación ...

Recuerde: Todo el código se puede reducir al menos 1 instrucción. Todo el código tiene al menos 1 error. Por lo tanto, todo el código puede reducirse a una sola instrucción que no funciona. ¡Espero que ayude!