Existen diversos tipos de calidad que se pueden medir en productos de software, por ejemplo, idoneidad para el propósito (por ejemplo, uso final), mantenibilidad, eficiencia. Algunos de estos son algo subjetivos o específicos del dominio (por ejemplo, los buenos principios de diseño de GUI pueden ser diferentes entre culturas o dependen del contexto de uso, piense en el uso militar versus el uso del consumidor).
Lo que me interesa es una forma más profunda de calidad relacionada con la red (o gráfico) de tipos y su interrelación, es decir, a qué tipos se refiere cada tipo, ¿hay grupos de interconectividad claramente identificables relacionados con un arquitectura escalonada, o por el contrario, hay una gran 'bola' de referencias de tipo (código 'monolítico'). Además, el tamaño de cada tipo y / o método (por ejemplo, medido en cantidad de código de bytes Java o .Net IL) debería dar alguna indicación de dónde se han implementado algoritmos complejos grandes como bloques de código monolíticos en lugar de descomponerse en más manejables / mantenibles trozos
Un análisis basado en tales ideas puede calcular métricas que son al menos un proxy de calidad. El umbral exacto / puntos de decisión entre alta y baja calidad sospecharía que es subjetivo, por ejemplo, ya que por mantenibilidad nos referimos a mantenibilidad por parte de programadores humanos y, por lo tanto, la descomposición funcional debe ser compatible con el funcionamiento de las mentes humanas. Como tal, me pregunto si alguna vez puede haber una definición matemáticamente pura de la calidad del software que trascienda todo el software posible en todos los escenarios posibles.
También me pregunto si es una idea peligrosa, que si los representantes objetivos de calidad se vuelven populares, las presiones comerciales harán que los desarrolladores busquen estas métricas a expensas de la calidad general (aquellos aspectos de la calidad no medidos por los representantes).
Otra forma de pensar sobre la calidad es desde el punto de vista de la entropía. La entropía es la tendencia de los sistemas a revertir de estados ordenados a desordenados. Cualquiera que haya trabajado en un mundo real, un proyecto de software de mediana a gran escala apreciará el grado en que la calidad de la base del código tiende a degradarse con el tiempo. Las presiones comerciales generalmente resultan en cambios que se centran en la nueva funcionalidad (excepto donde la calidad en sí misma es el principal punto de venta, por ejemplo, en el software de aviónica), y la erosión de la calidad a través de problemas de regresión y la funcionalidad de 'horquilla' donde no encaja bien Una perspectiva de calidad y mantenimiento. Entonces, ¿podemos medir la entropía del software? Y si es así, ¿cómo?
fuente
Respuestas:
Esta es una idea peligrosa. Los representantes "objetivos" de calidad conducen directamente a recompensas de gestión y los desarrolladores buscarán estas métricas a expensas de la calidad real.
Esta es la ley de las consecuencias no deseadas.
La calidad, aunque importante, es solo un pequeño aspecto del software. La funcionalidad y el valor creados por el software son mucho, mucho más importantes que la calidad.
Todas las métricas conducen a la actividad para optimizar la métrica. Eso, a su vez, tiene consecuencias que quizás no te gusten realmente.
El software es muy complejo. Es difícil entender lo verdaderamente complejo que es.
Incluso cosas tan "obvias" como la cobertura del código de prueba de unidad pueden perder el tiempo. Llegar al 100% puede requerir la creación de pruebas que en realidad son más complejas que el código trivial que se está probando. Llegar al 100% de cobertura puede implicar un costo inaceptable. [La alternativa para el código trivial, pequeño y poco utilizado es prueba por inspección. Pero eso no se ajusta al juego de métricas del 100%.]
Otro ejemplo es la Complejidad Ciclomática. Es una de las mejores medidas de calidad del código. Pero se puede jugar creando muchas funciones pequeñas que pueden ser más difíciles de leer (y más difíciles de mantener) que una función más grande. Termina en revisiones de código donde acepta que puede no ser muy legible pero cumple con el umbral de complejidad.
fuente
Bingo, y no "si" al respecto. Esto se llama "disfunción de medición" y se ha observado y escrito muchas veces sobre Joel escribió un artículo sobre él en 2002 refiriendo un libro de un profesor de Harvard.
Eso no significa que tales métricas sean inútiles, solo que uno nunca debe basar incentivos o políticas explícitamente en tales mediciones proxy. Si desea mejorar la calidad, una métrica de proxy con un valor muy malo es probablemente un buen punto para comenzar. Pero no puede concluir que la calidad es buena solo porque todas sus métricas tienen grandes valores.
fuente
Esto suena como fan-in y fan-out. Fan-in cuenta el número de módulos que llaman a un módulo dado y fan-in cuenta el número de módulos llamados por un módulo dado. Una señal de advertencia para usar serían los módulos que tienen un gran abanico de entrada y un gran abanico de salida, ya que esto podría indicar un diseño deficiente y un objetivo clave para la refactorización o el rediseño.
Una medida simple sería líneas de código. Podría dividirlo en líneas de código totales en todo el proyecto y líneas de código por módulo (quizás utilizando módulos de diferentes tamaños). Puede usar esto como un indicador de advertencia que indica que debe revisar módulos particulares. Un libro sobre mediciones y métricas de calidad de software analiza algunos trabajos que indican que la relación entre las tasas de defectos y el tamaño del módulo es curvilínea, donde el defecto promedio por KSLOC viene con módulos con un tamaño entre 175 y 350 SLOC.
Algo un poco más complejo sería la complejidad ciclomática, que está diseñada para indicar la capacidad de prueba, comprensibilidad y mantenibilidad de un sistema. La complejidad ciclomática cuenta el número de rutas independientes a través de una aplicación o módulo. El número de pruebas, y por lo tanto el esfuerzo necesario para producir y ejecutar las pruebas, está fuertemente relacionado con la complejidad ciclomática.
No estoy seguro de que sea así.
Por ejemplo, ha habido investigaciones que sugieren que la memoria de trabajo de un humano solo puede contener 7 objetos más / menos 2 . Esto probablemente sea de interés para medir la entrada y salida del ventilador: si estoy trabajando en un módulo y está conectado a más de ~ 7 otros módulos, probablemente no podré hacer un seguimiento de exactamente qué Otros módulos están en mi cabeza.
También se ha trabajado en relacionar defectos con métricas como la complejidad ciclomática. Dado que desea minimizar los defectos en su sistema, puede identificar puntos que necesitan más pruebas de esfuerzo o refactorización, como lo identifica la alta complejidad ciclomática.
Este es el caso con cualquier medida o métrica. Deben usarse para comprender el sistema y tomar decisiones informadas. Me viene a la mente la frase "no puedes manejar lo que no puedes medir". Si desea un software de alta calidad, necesita algunas mediciones y métricas para evaluar esa calidad. Sin embargo, hay una otra cara de esto. No se puede administrar exclusivamente por los números. Puede usar los números para tomar decisiones informadas, pero no puede tomar una decisión solo porque los números lo dicen.
fuente
Existen indicadores o indicadores para muchas de las cualidades que le interesan:
Hay algunos problemas con todos estos elementos:
El efecto total de estos problemas es que las métricas como estas probablemente sean valiosas solo dentro de una cultura más amplia, como TQM, garantía de calidad (no control), mejora continua, kaizan, etc. Es necesario definir elementos de ambas culturas. y cómo necesita cambiar. Si tiene una definición de estos, las métricas como estas se convierten en herramientas esenciales para ayudar a mejorar la calidad del código, las prácticas de trabajo, la productividad, etc. Sin este contexto más amplio, las métricas generarán trabajo para optimizar la métrica; se convertirá en la herramienta del contador de frijoles para aumentar la productividad y disminuir los costos; y se convertirá en un obstáculo para ser jugado por el personal de desarrollo.
fuente
Podría estar obsesionado con las métricas, o podría estar obsesionado con las mejores personas, herramientas, prácticas de ingeniería y control de calidad que puede pagar. Sería mucho más feliz tener varios genios paranoides de control de calidad que hayan leído 'Engañado por la aleatoriedad' y que les guste automatizar que un montón de informes con números bien formateados.
fuente
Existe este problema fundamental con las métricas.
Se ha demostrado que casi todas las métricas propuestas, en el mundo real en código real, están fuertemente o muy fuertemente correlacionadas con SLOC sin formato (líneas de código fuente).
Esto es lo que mató las métricas de Halstead, en la década de 1970. (Por accidente, un día, alrededor de 1978, me senté en una charla de un nuevo doctorado sobre las métricas de Halstead, en el que señaló esto).
Más recientemente, se ha demostrado que la complejidad ciclomática de McCabe se correlaciona muy fuertemente con SLOC sin procesar, hasta el punto de que el tipo que realizó el estudio se preguntó en voz alta si la métrica de McCabe nos decía algo útil.
Hemos sabido durante décadas que los programas grandes tenían más probabilidades de tener problemas que los pequeños. Hemos sabido durante décadas que las grandes subrutinas tenían más probabilidades de tener errores que las pequeñas. ¿Por qué necesitamos métricas arcanas para decirnos esto, cuando mirar cuatro páginas de impresoras distribuidas en una tabla debería ser lo suficientemente convincente?
fuente
Dadas todas las otras respuestas aquí, me siento un poco tonto con esta pequeña. Eche un vistazo a Crap4j , que trata de clasificar los métodos en java por cuánto apestan. (El proyecto parece abandonado).
Utiliza una combinación de complejidad ciclomática y cobertura de prueba. Como cualquier otra métrica, es jugable.
fuente