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
|
