lunes, 28 de enero de 2013

Métricas de código en Visual Studio


Visual Studio incorpora “de serie” unas métricas que código que nos ofrece una mayor visibilidad sobre la calidad del código que se está desarrollando. El análisis del código de un determinado proyecto/solución se puede hacer a demanda desde el menú Analizar – Calcular métricas de código para el proyecto/solución o haciendo clic con el botón derecho del ratón sobre el proyecto concreto (explorador de soluciones).

El resultado del análisis se mostrará en la ventana “Resultados de métricas del código”.


El analizador nos muestra 5 métricas por método:

·         Índice de Mantenibilidad: Utiliza un algoritmo para, atendiendo al resto de las métricas, ofrecer un valor comprendido entre 0-100. Cuanto más cercano a 100 más mantenible es el software. El analizador muestra una codificación por colores:
o    Verde [20, 100] à mantenimiento bueno.
o    Amarillo entre [10, 19] à mantenimiento moderado.
o    Rojo [0, 9] à mantenimiento pobre.

Después de analizar varios de nuestros proyectos hemos observado que en ninguno de los casos se muestra un valor amarillo o rojo, por lo que, o bien todos nuestros proyectos tienen una calidad extraordinaria (con el código heredado y las prisas en el desarrollo de determinados proyectos no me lo creo) o bien tendremos que afinar el umbral a partir del cual consideramos necesario inspeccionar/mejorar el código. Inicialmente nos planteamos mantener este valor por encima de 50 y se irá ajustando según vayamos ganando experiencia con la métrica.

·         Complejidad ciclomática: representa la complejidad estructural de una porción de código. Se calcula sumando las instrucciones condicionales, los bucles, las salidas (return extras) de los métodos y las cláusulas AND y OR dentro de los condicionales. A mayor valor de esta métrica peor mantenibilidad.

McConnell en CODE COMPLETE argumenta que está generalmente aceptado para lenguajes como java o C# que esta métrica sea menor que 10 aunque en determinados entornos se han obtenido buenos resultados con un umbral de 15. Nos planteamos no ser demasiado estrictos con esta métrica. Hemos encontrado, por ejemplo, funciones de conversión de cantidades numéricas a letras que requieren de un gran número de estructuras condicionales y aunque la complejidad ciclomática de esta función sea elevada su alta cohesión no parece aconsejar su división en varias funciones para mejorar la complejidad.

·         Profundidad de Herencia: Cuanto más profunda es la jerarquía de la herencia de las clases involucradas en un determinado método, más complicado es entender el código. Diferentes estudios indican que a partir de un nivel de jerarquía de 4 la mayor parte de los programadores tenemos problemas para entender el código.

·         Acoplamiento de clases: mide las relaciones que el método en análisis tiene con otras clases a través de parámetros, variables locales, tipos de valores devueltos, llamadas a métodos, implementaciones de interfaces, etc. Un acoplamiento muy elevado indica que el diseño presenta o presentará futuros problemas de mantenibilidad. Debido a que esta métrica está muy asociada al tiempo de diseño es importante tenerla “bajo control” en momentos tempranos del proyecto puesto que su resolución futura puede ser bastante más complicada que, por ejemplo, la complejidad ciclomática que podemos solucionar extrayendo un método nuevo.

·         Líneas de código: número de líneas de código de un método sin contar espacios ni comentarios. Si el número de líneas de código es demasiado elevado, esto indica que el método está intentando hacer demasiadas cosas, síntoma de baja cohesión y de difícil mantenibilidad. Hay mucha discrepancia en cuanto al número adecuado de líneas de código, pero en lenguajes tipo java o C# un umbral generalmente aceptado son las 50 líneas.

En cualquier caso, una buena práctica extendida es intentar que un método se visualice por completo en la pantalla sin necesidad de utilizar la barra de desplazamientos, esto facilita el seguimiento en tiempo de depuración y una buena estructuración en tiempos de construcción.

Dependiendo del tipo de proyectos, arquitecturas utilizadas y tiempo de vida del proyecto los umbrales podrán variar, nosotros después de una breve inspección de varios proyectos que actualmente se encuentran en fase de mantenimiento hemos definido la siguiente tabla, como punto de partida para posteriormente adaptarlos:

Índice de Mantenibilidad
Complejidad Ciclomática
Profundidad de herencia
Acoplamiento de clases
Líneas de código
>50
<10
<4
<7
<25

3 comentarios:

  1. Nadie dice que es necesario la versión Premium para tener esa opción.

    ResponderEliminar
  2. Amigo como puedo calcular el indice de mantenimiento de mi codigo sin utilizar visual estudio. De forma manual

    ResponderEliminar
  3. Por lo general se espera que el indice de mantenibilidad (en donde el atributo de calidad del proyecto es obviamente el mantenimiento) es superior o igual al 75%

    ResponderEliminar