Hace ya algún tiempo recibí, como seguramente ocurrió con muchos de ustedes, un mail de Gustavo consultando si tenía algún aporte para hacer sobre análisis estático de código. La verdad es que poco y nada pude colaborar en ese momento, pero su pregunta disparó mi curiosidad y me puse a revisar un poco el tema.
Comencé por la nota que publicó Gustavo leí sobre estas herramientas y decidí levantar un servidor de Sonar para jugar un poco y experimentar. Costó algunas horas ponerlo en funcionamiento, pero lo pude hacer correr y analizar código. Había mucha información, algunos términos cómo complejidad ciclomática los conocía, pero otros como deuda técnica y mantenibilidad no tanto. Leí y aprendí, pero en casi todo lo que leía se hacía referencia al análisis estático de código como una tarea del desarrollador, puede ser, no niego que sería más que interesante que desarrollo realice estos análisis, sobre todo los manuales que requieren un conocimiento técnico elevado en cuanto al lenguaje analizado y a conceptos de programación. Sin embargo, en mi experiencia tanto como probador o programador, esto no sucede. Independientemente de esto, considero que conocer estos conceptos y saber leer los análisis que estas herramientas proveen es importante para la tarea del testing, sobre todo si se implementan políticas de calidad serias donde no sólo importe cuánto desvío hubo entre la fecha prometida y la fecha de entrega.
Como probadores de software somos parte de Calidad, hacemos el control de calidad y esto debería involucrar conceptos como la mantenibilidad y la deuda técnica, una política de calidad debería contemplar cuál es el límite de mantenibilidad y cuál es un porcentaje de deuda técnica aceptable e, independientemente de lo que haga desarrollo, testing debería ser capaz de entender estos conceptos y controlarlos. Por eso los invito a familiarizarse con estos conceptos y también, desde el lugar que puedan, a comenzar a darles notoriedad y peso dentro de su área de trabajo porque… que algo haga lo que tiene que hacer, no necesariamente quiere decir que fue construido con Calidad.
- Mantenibilidad
- Deuda técnica
- Complejidad ciclomática
- Complejidad ciclomática, o la métrica esencial para evaluar el diseño de software
- Complejidad ciclomática ¿Nuestro código es fácil de mantener y prob
Autor:
Martin Cejas
https://ar.linkedin.com/in/mcejas
