Charla GSAS: Métricas para arquitectos

Last October, I had the opportunity to attend the Global Software Architecture Summit, an event organized by Apiumhub in Barcelona. One of the talks I enjoyed the most during the event was “Metrics for Architects” by Alexander von Zitzewitz, founder and CEO of hello2morrow. During his presentation, Alexander shared several metrics for architects that should be taken into account as a project progresses to prevent the development of spaghetti code and ensure the final product is easy to maintain and free of bugs.

¿Por qué utilizar métricas para arquitectos?

Estos son algunos de los puntos que Alexander trató durante su charla Métricas para arquitectos:

– Las métricas son la base del crucial nodo «verificar/medir» del bucle de mejora continua. Lo que se mantiene medido, se puede mejorar.

– Herramientas gratuitas que facilitan su medición

– La medición automatizada en las compilaciones CI permite descubrir tendencias perjudiciales con suficiente antelación (y romper la compilación).

– Puede hacer cumplir las normas de calidad utilizando métricas en las puertas de calidad

– Algunas métricas son excelentes funciones fitness de arquitectura

Si estas razones no son suficientes, puede leer un informe de The Evolving Enterprise.

La mala calidad del software costó a EE.UU. 2,08 billones de dólares en 2020.

El informe que he mencionado antes habla de cómo el software de baja calidad cuesta mucho dinero. Algunas conclusiones relevantes son:

• Los proyectos fallidos cuestan 260.000 millones de dólares, un 46% más que en 2018
• Los problemas del sistema heredado contribuyeron a unos 520.000 millones de dólares

Este informe también ofrece algunas recomendaciones:

• Garantizar el análisis temprano y periódico del código fuente para detectar infracciones, puntos débiles y vulnerabilidades.
• Medir las características de calidad estructural.
• Reconocer las dificultades inherentes al desarrollo de software y utilizar herramientas eficaces que ayuden a superarlas.

Entonces, ¿por qué nadie utiliza métricas para los arquitectos?

El informe es claro: hay que analizar el código para encontrar problemas. ¿No conocemos las herramientas existentes? O puede que no sepamos qué métricas conviene emplear, dadas las numerosas opciones disponibles. Además, es crucial tener en cuenta que una sola métrica por sí sola es insuficiente para obtener resultados precisos; puede ser necesaria una combinación de métricas.

¿Cómo medir la espaguetización del código?

¿Cuáles son las características del código espagueti? El código tiene un alto acoplamiento, demasiadas dependencias circulares, no hay una separación clara de responsabilidades, las funciones están dispersas por todas partes y a veces podemos encontrar algunas duplicaciones.

Si comparamos un código espagueti con un código limpio, veremos que tener una buena base de código puede reducir drásticamente el coste, el tiempo y la calidad de un proyecto.

Código Spaghetti	Clean code
Velocidad del equipo muy reducida	Mejora de la productividad de los desarrolladores
Errores de regresión frecuentes	Menor riesgo
Difícil de mantener, probar y comprender	Más fácil de mantener, probar y comprender
La modularización es imposible	Coste de cambio mucho menor

Herramientas para la recopilación de métricas

– Comprender (comercial) scitools.com

• NDepend (comercial, .Net) ndepend.com

• Sonargraph-Explorer (gratis) hello2morrow.com

• SourceMonitor (gratis) https://www.derpaul.net/SourceMonitor/

Buenas métricas para que los arquitectos midan el deterioro estructural

Revisemos algunas buenas métricas que pueden ayudarnos a evitar el deterioro de nuestro proyecto:

• ACD (Average Component Dependency): mide el acoplamiento.
  • Esta es una métrica de acoplamiento.
  • Nos da el número medio de dependencias directas e indirectas
• Ciclicidad relativa – se centra en las dependencias cíclicas
• Índice de deuda estructural: análisis mejorado de las dependencias cíclicas
• Nivel de mantenimiento: mide el acoplamiento, la verticalización y los ciclos.

Dependencias cíclicas

Esto ocurre cuando la clase A depende de B, B de C y C de nuevo de A.

¿Por qué son malas las dependencias cíclicas?

• Las pruebas se hacen más difíciles
• La modularización se hace más difficultad
• Aumenta el acoplamiento
• Deben evitarse los grupos de ciclos con más de 5 elementos
• Los ciclos Namespace / Package son especialmente malos y deberían romper la compilación.

Al final, deberíamos ser capaces de romper todos los ciclos.

Métricas para dependencias cíclicas:

• Número de grupos ciclistas / mayor tamaño del grupo ciclista
• Ciclicidad / Ciclicidad relativa
• Índice de deuda estructural

Ciclicidad

La ciclicidad de un grupo de ciclos es el cuadrado de su tamaño, por ejemplo, un grupo con 3 elementos tiene una ciclicidad de 9. La ciclicidad del sistema/módulo es la suma de todos los valores de ciclicidad del grupo de ciclos. Cuanto mayor sea el número, mayor será el número de clases implicadas en un ciclo, que puede ser mucho más difícil de romper.

Índice de deuda estructural

Esta métrica se centra en el acoplamiento cíclico y en lo difícil que sería romper los ciclos

Las dependencias cíclicas son un buen indicador de la erosión estructural

Para cada grupo de ciclos, se calculan dos valores:

¿Cuántos eslabones tengo que cortar para romper el ciclo del grupo?

Número total de líneas de código affectadas por los enlaces a romper.

SDI = 10 * LinksToBreak + TotalAffectedLines

A continuación, se suman las IDE de los módulos y de todo el sistema

Puede calcularse a nivel de componente y a nivel de paquete/espacio de nombres.

Nivel de mantenimiento

Métrica experimental en Sonargraph

Aplicado en porcentaje: 100% significa que no hay acoplamiento

Debe ser estable, cuando no haya cambios importantes en la arquitectura y el diseño.

Desvinculación de las medidas y éxito de la verticalización

Reducir el acoplamiento y la ciclicidad mejorará la métrica

Uno de varios indicadores de la calidad del diseño

Valor recomendado: 75% o más

Complejidad ciclomática

Umbral recomendado: CCN <= 15

• Complejidad ciclomática media
  • Puede calcularse sobre clases, paquetes/espacios de nombres o módulos.
  • La media ponderada de los valores de complejidad ciclomática de los métodos/clases.
  • Utilizar el «número de declaraciones» como ponderación
• Profundidad máxima de indentación
  • Un muy buen indicador de complejidad
  • Una secuencia de sentencias condicionales o bucles suele ser menos compleja que un conglomerado profundamente anidado de bucles y sentencias condicionales
  • Umbral recomendado: MID <= 4
• LCOM 4
  • Presentado por Chidamber & Kemerer.
  • Calcula el número de grupos cohesionados dentro de una clase.
  • Un grupo cohesionado está formado por campos y métodos que interactúan entre sí.
  • Los métodos y constructores anulados se ignoran.
  • Un valor de 1 significa cohesión perfecta
  • Los valores mayores significan que la clase puede dividirse en varias clases.
  • No siempre funciona bien en jerarquías de herencia. Funciona mejor con clases no derivadas de otras clases excepto ‘Objeto’.

Métricas de arquitectura por Robert C. Martin

Para finalizar la charla, se comentaron algunas métricas del Tío Bob:

• Inestabilidad (I)
  • Esta medida se emplea para evaluar hasta qué punto una clase es vulnerable a las alteraciones.
  • Di = Número de relaciones entrantes
  • Do = Número de dependencias salientes
  • Inestabilidad I = Do / (Di+Do)
• Abstracción
  • La abstracción se determina dividiendo el número total de clases abstractas de un paquete por el número total de clases de ese paquete.
  • Nc = Número total de tipos en un contenedor de tipos
  • Na = Número de clases abstractas e interfaces en un contenedor de tipos
  • Abstracción A = Na/Nc
• Distancia
  • una métrica que cuantifica el equilibrio entre estabilidad y abstracción
  • D=A + I – 1
  • Rango de valores [-1 .. +1]
  • Los valores negativos están en la «Zona de dolor»
  • Los valores positivos pertenecen a la «Zona de inutilidad»
  • Los valores buenos son próximos a cero (por ejemplo, de -0,25 a +0,25)

Conclusiones sobre la charla métricas para arquitectos

El tema principal de esta edición del GSAS fueron las métricas y en esta charla de Alexander von Zitzewitz fue probablemente donde más métricas se mostraron. Alexander presentó varias métricas que, utilizadas colectivamente, pueden ayudar a evaluar la calidad de un proyecto e identificar las áreas que requieren mejoras. Sin embargo, es sorprendente que, a pesar de su valor potencial, a menudo no se preste suficiente atención a las métricas. Este puede ser uno de los motivos por los que, como sugiere el informe, muchos proyectos fracasan.

¿Te interesa asistir al GSAS? La edición de este año se centrará en las prácticas modernas de arquitectura de software: cómo ser más eficaz, eficiente y disfrutar con lo que se hace. Líderes del sector como Mark Richards, Neal Ford, Jacqui Read, Diana Montalion, Sandro Mancuso, Eoin Woods y muchos más estarán allí para compartir sus conocimientos y experiencia con los asistentes. Las entradas ya están a la venta, no pierdas la oportunidad de asistir. Consigue tus entradas aquí.