¿Cómo mediría la "calidad" del código en un gran proyecto?

Question

Estoy trabajando en un proyecto bastante grande, de unos pocos años en una empresa bastante grande, y estoy asumiendo la tarea de conducir hacia una mejor calidad de código general.

Me preguntaba qué tipo de métricas utilizarías para medir la calidad y la complejidad en este contexto. No busco medidas absolutas, sino una serie de elementos que podrían mejorarse con el tiempo. Dado que esto es una especie de macrooperación en cientos de proyectos (he visto algunas preguntas sobre proyectos mucho más pequeños), estoy buscando algo más automatizable y holístico.

Hasta ahora, tengo una lista que tiene este aspecto:

• Código porcentaje de cobertura durante las pruebas completamente funcional
• la repetición de los fracasos BVT
• gráfico de dependencias/puntuación, basado en alguna herramienta como NDepend
• Número de advertencias de compilación
• Número de advertencias FxCop/StyleCop encontró/supressed
• Número de "CATC h" declaraciones
• Número de despliegue manual de los pasos
• Número de proyectos
• Porcentaje de código/proyectos que está 'muerto', como en, no hace referencia a ninguna parte
• Número de WTF de durante el código revisa
• El total de líneas de código, tal vez desglosada por niveles

Answer 1

tal vez te parezca interesante, o perspicaz, este análisis: A Tale of Four Kernels
Edit:schema, and the corresponding queries

Answer 2

Cyclomatic complexity es una métrica decente de "calidad". ¡Estoy seguro de que los desarrolladores podrían encontrar la manera de "jugarlo" si fuera la única métrica! :)

Y luego está la métrica C.R.A.P. ...

P. S. NDepend tiene aproximadamente diez mil millones de métricas, por lo que podría valer la pena mirar. Consulte también CodeMetrics para Reflector.

D'oh! Me di cuenta de que ya habías mencionado a NDepend.

Número de errores reportados sería interesante realizar un seguimiento, también ...

Answer 3

Cantidad de software cloning/duplicate code, menos es obviamente mejor. (El enlace analiza clones y varias técnicas para detectarlos/medirlos)

Answer 4

Si está asumiendo la tarea de conducir hacia una mejor calidad general del código. Puede consultar:

• ¿Cuántos problemas abiertos tiene en la actualidad y cuánto tardan en resolver?
• ¿Qué proceso tiene para reunir los requisitos?
• ¿Su personal sigue las mejores prácticas?
• ¿Tiene sop definido para describir la metodología de programación de su empresa.

Cuando tiene un número de desarrolladores involucrados en un gran proyecto, todos tienen su manera de programar. Cada estilo de programación resuelve el problema, pero algunas respuestas pueden ser menos eficientes que otras.

¿Cómo se puede utilizar su personal al atacar una nueva característica o corregir el código existente? Hacer que los desarrolladores trabajen en equipos siguiendo la programación de sop's obliga a todos a ser un mejor código.

Cuando su gente codifica de manera más eficiente siguiendo la regla, el tiempo de desarrollo debería ser más rápido.

Puede obtener todas las métricas que desee pero decir en primer lugar que hay que ver cómo se están haciendo las cosas:

¿Qué están las prácticas de desarrollo?

Sin saber cómo se están haciendo las cosas actualmente, puede obtener todas las métricas que desee, pero nunca verá ninguna mejora.

Answer 5

Debe organizar su trabajo alrededor de las seis principales características de calidad del software: funcionalidad, confiabilidad, facilidad de uso, eficiencia, facilidad de mantenimiento y portabilidad. He puesto un diagram online que describe estas características. Luego, para cada característica, decida las métricas más importantes que desea y puede rastrear. Por ejemplo, algunas métricas, como las de Chidamber y Kemerer, son adecuadas para el software orientado a objetos, otras, como la complejidad ciclomática, son más generales.