Métricas de código

Question

Tengo curiosidad acerca de qué tipo de métricas de código están usando las personas y opiniones/experiencia sobre el uso más efectivo de las métricas de código. Todo nuestro código, sin importar el idioma, utiliza la siguiente:

• Código Ciclomática Complejidad
• líneas de código
• acoplamiento (tiene diferentes significados para lenguajes orientados a objetos que en las lenguas de procedimiento y de plantillas)

La medida de complejidad ha sido la más efectiva para nosotros en la identificación de posibles pesadillas de mantenimiento. En menor medida, LOC también ha sido útil como una medida relativa (si vemos una clase que tiene 20 líneas más que la clase promedio). El acoplamiento ha sido menos útil, por lo general más útil cuando se analiza cuántas cosas podríamos romper con un cambio.

Me interesa saber qué están usando los demás (en todo caso) para obtener métricas de código y opiniones sobre las métricas enumeradas anteriormente.

Answer 1

Mi empresa actual realmente no conserva ninguna métrica de código, que no es mi elección.

Mi empleador anterior mantuvo las métricas sobre la complejidad del código y las líneas de código. También tenían límites en la longitud de los archivos de clase. Las clases que se volvieron demasiado grandes tuvieron que pasar por una revisión del código para poder dividirlas en clases más pequeñas y apropiadas. En ocasiones fue un dolor en el trasero, pero mantuvo lo que era una base de origen extremadamente grande (100 - 200 desarrolladores estaban en el proyecto) bastante fácil de mantener.

Answer 2

• pelusa
• Ciclomática complejidad
• Por desgracia, poco más

Answer 3

que hacemos actualmente cobertura de la prueba con EMMA como un plugin de Maven. Es bastante resbaladizo. Le dirá exactamente qué parte de su código se ejecuta con sus pruebas. Usamos JUnit para probar.

Answer 4

Uso regularmente la cuenta de Dave Wheeler que da LoC y también he probado CCCC, aunque ahora es un poco anticuado.

Answer 5

En Bell, calculamos Puntos de función en cada proyecto (consulte IFPUG).

Lo bueno: han creado una base de datos bastante grande de los costos del proyecto.

Lo malo: que no estaba funcionando tan pronto como algo se introdujo nueva - y puesto que la informática está evolucionando muy rápido, no había casi cada vez que algo nuevo ...

Conclusión: las métricas son bastante buenos en constante ambientes. Pero si cambia algunos parámetros, son un poco inútiles.

Sylvain.

Answer 6

He estado experimentando con el Metrics plugin for Eclipse from StateOfFlow y me gusta la idea de analizar la calidad de mi código.Por supuesto, no todas las métricas son demasiado claras o útiles, pero de la amplia gama de métricas que proporciona el complemento (actualmente 14, según mi recuento), tiendo a tomarlas en serio:

Métrica del método: Complejidad ciclomática | Número de declaraciones | Número de locales en el alcance | Número de niveles

Métricas de clase: Número de campos | métodos ponderados por clase

Para reducir esta lista aún más, realmente creo en Ciclomática Complejidad medida de McCabe y me encuentro con el número de declaraciones también una indicación bastante útil de demasiado trabajo que se realiza en un solo lugar.

Del resto de las métricas proporcionadas por el complemento, encuentro las de La falta de cohesión en los métodos grupo es bastante difícil de entender. Hoy, comencé con un pequeño experimento propio y después de un par de horas de codificación, inicié el soporte de Metrics para el proyecto. 6/7 los problemas encontrados se relacionaron con la cohesión, uno particularmente sorprendente: La falta de cohesión en los métodos (Correlación total) es del 209%.

Me resulta difícil hacer nada al respecto: Chidamber y Kemerer | Henderson-Sellers | Correlación total | Irrelación de campo por pares. Estoy muy tentado de aumentar los máximos permitidos para estas métricas, para que dejen de aparecer como advertencias.

Creo que tener métricas de código calculadas sobre la marcha proporciona una guía útil para escribir un mejor código. Me complace que haya hecho esta pregunta, ya que me gustaría leer más acerca de cómo los demás están usando métricas para mejorar la calidad del código.

Por cierto, agradecería cualquier recomendación de otros plugins (Eclipse) con los que pueda tener experiencia. El de StateOfFlow proporciona una buena forma de exportar la información de las métricas en forma de páginas HTML con gráficos y tablas, y también puede exportar métricas a archivos CSV que luego puede ingresar a cualquier otra utilidad que pueda estar usando. Estoy disfrutando el complemento hasta el momento :)

Answer 7

Obtienes lo que mides.

Por lo tanto, elija sus métricas cuidadosamente. Medir lo equivocado te da lo incorrecto. No todos los objetivos se pueden medir directamente, por lo que tendrá que conformarse con un proxy que se correlacione con el objetivo.

---

En el último proyecto que completé, medí lo siguiente. Estas no son exactamente métricas de código, sino métricas de proyecto de nivel más alto. Creo que todavía está relacionado con esta pregunta.

• acumulación Daily tasa de fracaso (con análisis de la causa raíz de los fallos), el objetivo de < 20%
• carrera Exámenes/pasar tasas (tanto automatizada y pruebas manuales), objetivos diferentes por fase del proyecto; al final tasa de ejecución objetivo 100%, tasa de aprobación 95%
• Función de prueba y cobertura de decisión para código nuevo (no UI, no heredado, no portado), objetivo 100% para funciones API, 80% para otras funciones, 50 % para decisiones
• Conteo de errores abiertos por prioridad, objetivo para ver una curva plana o decreciente (capacidad de corrección de error del equipo es suficiente), sin errores abiertos de alta prioridad
• Inspección: Tamaño del componente, esfuerzo de inspección, problemas encontrados por gravedad ; objetivo para obtener una especie de medida heurística de defectos/esfuerzo/loc para asegurarse de que los componentes se inspeccionan a fondo
• Herramientas de análisis estático como pelusa y algunas herramientas específicas de dominio ejecutadas, problemas de alta prioridad resueltos o entendidos
• Estimación de velocidad del equipo vs actual por sprint, objetivo para disminuir el error de estimación a menos del 20%

Estas métricas se derivaron de los objetivos de mayor nivel que teníamos como proyecto. En pocas palabras, enviar un producto lo suficientemente bueno lo antes posible sin incurrir en demasiada deuda técnica.

La mayoría de los problemas de "métrica de código" se revisaron informalmente como parte de la inspección. Teníamos una sensación bastante buena del sistema, así que sabíamos dónde estaban las partes más complejas que requerían más atención. Como programadores, también pudimos detectar olores complejos sin recurrir a medidas formales.

Answer 8

Essential Cyclometric Complexity es interesante y da una indicación de qué tan "desestructurado" es el código.

El código no estructurado es el uso de roturas y gotos, por ejemplo, para salir de estructuras de control, como bucles.

Sin embargo, el único producto que conozco que da esta métrica es McCabe IQ

Answer 9

de Scott Hanselman tenía recientemente hizo un muy buen podcast en exactamente esto. Intente aquí: http://www.hanselminutes.com/default.aspx?showID=181

Answer 10

Creo que el Type Rank y las métricas de código de método de método son extremadamente útiles cuando necesita obtener una descripción general rápida de los tipos/métodos clave en su código. Tipo y método El rango está inspirado en el famoso Google Page rank algorithm.

Si se encuentra en un entorno .NET, NDepend calculará el Rango Rango tipo y método para usted (así como otras 80 métricas de código)

Answer 11

Hay bastante literatura científica sobre este. Se puede encontrar una encuesta en Nachiappan Naggapan's thesis (Lo siento, no pude encontrar un mejor acceso a la tesis). Otra presentación sobre las métricas del software es here.

Vine a conocer algunas de las métricas, como la métrica de flujo de información de Henry y Kafura, después de ejecutar CCCC recientemente en una base de código C++. CCCC es de código abierto y genera un resultado integral (sample) que consta de 2-3 medidas diferentes.