Page tree

 

Ya soy un experto y estoy aquí para ayudar: ¡contesta preguntas pendientes y gana puntos!

Skip to end of metadata
Go to start of metadata

Tabla de contenidos

En el catalogo de pecados del desarrollo, una mala distribución de la complejidad puede parecerse al pecado moral de la "gula". Pero en lugar de intentar llenar de demasiada comida el cuerpo, el desarrollador intenta llenar de lógica un método o una clase.

Es natural que un programa tenga algo de complejidad en sus ficheros y métodos (igual que también es normal tomar postres golosos de vez cuando), pero si existen demasiados, entonces lo que habrás conseguido es llenar un barreño de código spaghetti (continuando la metáfora de la comida). Esto significa que el siguiente desarrollador que tenga que trabajar en tu aplicación tendrá que perder mucho tiempo entendiendo que está pasando en ese código. Y si pierde mucho tiempo entendiéndolo, imagínate el tiempo que perderá modificándolo.

Además, el código complejo es muy difícil de probar adecuadamente. Y si es muy difícil de probar, entonces el riesgo de modificarlo se incrementa porque no tienes una salvaguarda contra la introducción de defectos y problemas de regresión.

Analizando la complejidad

Widget de complejidad

Añade el widget de Complejidad en el cuadro de mando de un proyecto:

Y echa un vistazo a la distribución para detectar si tienes muchos métodos complejos o ficheros. Idealmente, la gráfica debería concentrar todos los datos en la parte izquierda. Tener un pocos ficheros o métodos en la parte de la derecha es normal, especialmente en proyectos grandes, pero tener demasiados se convierte en un problema.

Encontrando los componentes más complejos

Hay dos formas de encontrar los componentes más complejos. La primera de ellas es navegar a través del widget de Complejidad. La segunda es añadir en tu cuadro de mando el widget de Métrica de Puntos críticos y añadir algunas métricas relacionadas como son la complejidad por fichero, la complejidad por método, etc. para poder "cazar" los componentes más complejos de tu proyecto.

 

  • No labels

2 Comments

  1. Muchas gracias Antonio. Una pregunta respecto a estos indicadores. Lógicamente, como indicas, entiendo la utilidad para analizar desde un punto de vista de "arquitectura" de desarrollo estos indicadores pero ¿crees que podría utilizarse el indicador de complejidad total para valorar el coste o la producción de SW de un proyecto JAVA?. Si se quisiera analizar el código con Sonarqube en este sentido, ¿que métricas crees que aportarían más utilizando Sonarqube?, muchas gracias.

    1. Hola Pedro, el coste total de un proyecto SW es difícil de valorar solo viendo el código fuente. Hay varios indicadores como COCOMO o por puntos función, pero no encuentro ningún plugin que lo implemente en SonarQube.

      Dado que SonarQube utiliza la deuda técnica para el coste de remedio con el método SQALE, te aconsejo que para ser práctico utilices ese modelo. En la implementación de SonarQube, para estimar el coste de desarrollo se puede utilizar indistintamente la complejidad o las líneas de código (se configura en el apartado de deuda técnica en la sección de configuración general global). Se establece un valor de coste por línea (o por unidad de complejidad), y a partir de ahí se calcula el coste de forma proporcional. SonarQube incluye valor por defecto, 30 minutos por cada línea de código. Lo que significa que un proyecto de 1.000 líneas tendrá un coste de 30.000 minutos, o lo que es lo mismo, 500 horas o 62 días (smile)

      Lo mejor es calibrar primero esos costes con el histórico de tus proyectos y tu equipo de desarrollo, y configurarlo acorde a la capacidad de tu organización. Y si no, pues usa el valor por defecto.