¿Cómo saber si el software es bueno o malo basado en métricas empíricas?

18

Actualmente me piden que mire un proyecto que ha terminado el desarrollo central hace cinco meses, pero que aún tiene un alto nivel de defectos. Lo que sucede es que por cada 10 defectos corregidos, levantamos al menos 4 y en algunos casos 8 defectos.

Creo que la práctica de codificación en el proveedor es deficiente y existe un acuerdo general al respecto. Sin embargo, me pregunto si hay un problema estructural con el software. La densidad del defecto es una medida útil, pero más si el software central está mal escrito, entonces todo lo que el proveedor está haciendo es cambiar el problema.

En infraestructura, está más definido si algo está mal construido, ¿qué medidas puede usar para el software además de los defectos por LOC?

El producto ha estado en fase de reparación de defectos durante 4 meses y aún no ha resuelto suficientes defectos críticos. No estamos inyectando nueva funcionalidad, solo solucionamos problemas de regresión.

Esto indica un problema de calidad de desarrollo que no está satisfecho. Sin embargo, si el producto en sí es fundamentalmente defectuoso, ese es un problema diferente. La preocupación es que la base del código central ha sido mal escrita y tiene documentación limitada, todo lo que los desarrolladores externos están haciendo es cambiar el problema de A a B. Una vez que los equipos de desarrollo internos se hacen cargo, me preocupa que tengan que reescribir fundamentalmente el código para hazlo funcional.

Entonces, cuando acepta un producto de un tercero y se le pide que lo respalde, ¿qué criterios de aceptación usaría para definir los estándares?

Además de hacer que nuestro desarrollador principal realice una revisión por pares del código por versión, ¿no está seguro de qué más se puede hacer?

Tecnología nómada
fuente
8
Si hubiera una métrica empírica útil (computable automáticamente) para un buen software, la gente la usaría en documentos de requisitos. Los escritores de compiladores simplemente lo optimizarían. Nunca podría haber desacuerdos sobre lo bueno que es el software. Claramente, el mundo no es así. Esa es una fuerte pista de que tal medida no existe, o al menos no se conoce ninguna.
Kilian Foth
2
Posible duplicado de la métrica para responsabilizar a los desarrolladores
mosquito
Los defectos se producen por muchas razones: fallas con la especificación, fallas con las pruebas, requisitos poco claros / cambiantes. No todos pueden atribuirse a fallas del desarrollador.
Robbie Dee
metafísica wrt debates, considere la posibilidad de una lectura a las discusiones y por qué no hacen buenas preguntas
mosquito
1
La pregunta puede ser redactada subóptimamente con demasiado énfasis en los defectos. Creo que la pregunta en el título es válida y no un duplicado (juzgando la calidad de sw aquí vs la productividad del desarrollador en la pregunta vinculada)
Frank

Respuestas:

23

Usted no

La calidad del software es realmente difícil de medir objetivamente. Lo suficientemente difícil como para que no haya una solución. Me estoy refrenando en esta respuesta para analizar la cuestión de si puede haber una solución, pero simplemente señalar por qué definirla sería realmente difícil.

Razonamiento por status quo

Como señaló Kilian Foth, si hubiera una medida simple para el "buen" software, todos lo estaríamos usando y todos lo exigirían.

Hay proyectos en los que los gerentes decidieron aplicar ciertas métricas. A veces funcionaba, a veces no. No tengo conocimiento de ninguna correlación significativa. El software de sistemas especialmente críticos (piense en aviones, automóviles, etc.) tiene muchos requisitos de métrica para "garantizar" la calidad del software. No conozco ningún estudio que demuestre que estos requisitos realmente den como resultado una mayor calidad, y tengo experiencias personales con el contrario.

Razonamiento por contrainteligencia

También lo insinuó Kilian, y en general se expresó como "todas las métricas pueden y serán jugadas".

¿Qué significa jugar una métrica? Es un juego divertido para desarrolladores: te aseguras de que los valores de las métricas se vean realmente bien, mientras haces cosas realmente malas.

Supongamos que mide defectos por LOC. ¿Cómo voy a jugar eso? Fácil: ¡solo agregue más código! Cree un código estúpido que resulte en una no operación en más de 100 líneas y de repente tenga menos defectos por LOC. Lo mejor de todo: en realidad disminuyó la calidad del software de esa manera.

Se abusa de las deficiencias de las herramientas, las definiciones se extienden al máximo, se inventan formas completamente nuevas ... básicamente, los desarrolladores son personas realmente inteligentes y si solo tienes un desarrollador en tu equipo que se divierta jugando métricas, entonces tus métricas serán cuestionables.

Esto no quiere decir que las métricas siempre sean malas, pero la actitud del equipo hacia estas métricas es crucial. En particular, esto implica que no va a funcionar bien para ninguna relación de subcontratista / proveedor de terceros.

Razonamiento por orientación incorrecta

Lo que quiere medir es la calidad del software. Lo que sí mide es una o más métricas.

Hay una brecha entre lo que mides y lo que crees que te dirá. Esta brecha es bastante grande incluso.

Sucede todo el tiempo en todo tipo de negocios a nuestro alrededor. ¿Alguna vez ha visto decisiones basadas en KPI (indicadores clave de rendimiento)? Es exactamente el mismo problema: desea que una empresa funcione bien, pero mide otra cosa.

Razonamiento por cuantificabilidad

Las métricas se pueden medir. Cuál es la única razón por la que tratamos con ellos. Sin embargo, la calidad del software se extiende mucho más allá de estas entidades medibles y tiene mucho que es muy difícil de cuantificar: ¿cuán legible es el código fuente? ¿Cuán extensible es tu diseño? ¿Qué tan difícil es para los nuevos miembros del equipo subir a bordo? etcétera etcétera.

Juzgar la calidad del software solo por métricas y hacer la vista gorda a las partes de la calidad que no puede cuantificar ciertamente no funcionará bien.

editar:

Resumen

Permítanme señalar que lo anterior se trata de juzgar objetivamente si el software es bueno o malo en función de las métricas. Esto significa que no dice nada sobre si debe aplicar métricas y cuándo.

De hecho, esta es una implicación unidireccional: las métricas incorrectas implican código incorrecto. Unidireccional significa que un código incorrecto no garantiza métricas incorrectas, ni las buenas métricas garantizan un código correcto. Por otro lado, esto en sí mismo significa que puede aplicar métricas para juzgar una pieza de software, cuando tenga en cuenta esta implicación.

Mide el software A, y las métricas resultan realmente malas. Entonces puede estar seguro de que la calidad del código es mala. Mide el software B y las métricas están bien, entonces no tiene idea de la calidad del código. No se deje engañar pensando "métricas buenas = código bueno" cuando en realidad es solo "código buenas => métricas buenas".

En esencia, puede usar métricas para encontrar problemas de calidad, pero no la calidad en sí misma.

Franco
fuente
Espere. De hecho, está diciendo que el software es similar a un texto, es decir, una forma de literatura. Comprenda que la comparación entre productos físicos y código es diferente. Sin embargo, las humanidades han estado marcando PHD durante mucho tiempo y tienen que cuantificar la calidad. Creo que el problema aquí es que, técnicamente, marcar el código es difícil. Pero aplique otras métricas, como dos aplicaciones por el mismo precio en una tienda de aplicaciones, pero una tiene más funcionalidad y una mejor calificación, esa es la que compra.
Tecnología nómada
Para su otro punto de medición, es la comparación. Si soporta tres productos diferentes, argumentaría que su función de soporte naturalmente le gustaría la que pueden leer el código fuente fácilmente y que los nuevos miembros adopten. Sería el producto sobre el que obtiene menos entradas / solicitudes de cambio. Entonces, en resumen, la respuesta es que no puede juzgar el código de software por sus líneas. Pero para los usuarios finales y aquellos que lo apoyan y si se puede mantener en el futuro con una interrupción mínima en los sistemas de producción.
Tecnología nómada
1
Estoy de acuerdo en que la calidad general del software es difícil de medir con una métrica, pero hay varias métricas que pueden señalar o tender a una menor calidad.
Jon Raynor
Ok, jugar una métrica puede ser un problema. Pero creo que lo que es aún peor es si me castigan por hacer lo correcto. Acabo de corregir un defecto reemplazando 100 líneas de código incorrecto con una llamada de biblioteca de una línea y ¿me estás diciendo que empeoré el código según tu métrica? Eso no me motivará a hacer un buen trabajo.
svick
Si está siendo "castigado", no está utilizando las métricas correctamente de todos modos. La vinculación de las métricas a la productividad del programador es una forma segura, aunque típica, de fallar.
Frank
13

Sí, puede ver que el código tiene problemas de calidad al observar las métricas hasta cierto punto.

Más específicamente, ejecute una herramienta de análisis de complejidad en la base del código y obtendrá una idea de si el código es bueno o malo.

Por ejemplo, podría ejecutar el monitor de origen .

Lo que esto le dirá es cuán complejo es el código. Les puedo decir que todos los sistemas problemáticos que he experimentado tenían números malos. Complejidad en 10s a 100s de métodos muy por encima de los límites aceptables. Números terribles Terrible complejidad, anidamiento, profundidad, etc. Esto provocará muchos problemas, una tasa de defectos alta constante, difícil de hacer cambios, sin romper otra cosa, etc.

Otra cosa son los defectos. Con el tiempo, el sistema debería estabilizarse. Idealmente, los defectos nuevos deberían tender hacia cero o aplanarse a un número bajo, lo que significa que los defectos nuevos y actuales deberían disminuir con el tiempo.

La trama debería verse así:

Defectos en el tiempo Defectos en el tiempo

Si se mantienen constantes o aumentan, entonces el software no es bueno. Sus solo 4 meses, así que le daría unos meses más a un año. Después de 6 meses a un año, si tuvo un flujo constante de defectos, entonces es de mala calidad. Su equipo desarrolló otra bola de lodo .

Próximas pruebas. ¿Los tienes? Si no, entonces menos calidad, más errores, más abandono. Si los tiene, las métricas como la cobertura del código son buenas para tener una idea de cuánto código se está cubriendo, pero no medirá la calidad . He visto excelentes números de cobertura de código, pero las pruebas reales fueron una mierda. No estaban probando ningún comportamiento o funcionalidad del sistema. Los desarrolladores simplemente los escribían para mejorar los números métricos para la administración. Entonces hay que hacerse pruebas y deben ser buenas. Las métricas de cobertura de código en sí mismas no son un indicador de calidad.

Revisiones de código, ¿las estás realizando? Si no, menos calidad. Esto es especialmente importante con los desarrolladores junior. Si está haciendo ágil, simplemente agregue una tarea de revisión de código a su historia llamada "revisión de código". Si la gerencia quiere rastrear números, necesitará una herramienta que rastree revisiones como Crucible . Creo que los números o las métricas de revisión del código no son tan importantes aquí aparte del hecho de que deberían ser parte de su proceso. No todos los registros necesitan una revisión. Pero las revisiones pueden ayudar a asegurar que las personas no reinventan la rueda o escriben código que otros no pueden entender y / o mantener.

Finalmente, solo va a tener que evaluar el código, ninguna métrica lo ayudará. Cada proyecto de código problemático tenía estas cualidades:

  • Pobres estructuras de datos. Todo es una cadena, o XML se pasa a todas partes y se analiza en todas partes, objetos divinos o estructuras de datos innecesariamente complejas o genéricas, sin modelo de dominio.
  • Falta de organización o estructura, cualquier proyecto no trivial debe tener alguna división o estratificación que separe la lógica. Eche un vistazo aquí ... Si no ve este tipo de organización o separación (mezcla de lógica en todas partes), entonces el sistema será más difícil de mantener y comprender.
  • Sobre abstracciones. A veces lo contrario es cierto, el sistema está demasiado abstraído. Si todo es una interfaz y una clase abstracta, o si tiene que navegar a través de una tonelada de clases de tipo "envoltorio", la calidad será mala porque los nuevos desarrolladores no podrán navegar a través de la expansión de objetos.
  • Código difícil de entender. Si eres un desarrollador experimentado y estás buscando un código difícil de entender, tendrá problemas de calidad. Mi métrica personal es que si estoy mirando el código y es difícil de seguir o me hace sentir tonto, o siento que estoy desperdiciando muchos ciclos cerebrales para descubrir la lógica, entonces es un mal código. Si los desarrolladores experimentados tienen dificultades para seguir, imagínense cómo será para los desarrolladores más nuevos. Introducirán problemas.

Mi consejo sería ejecutar un análisis de complejidad en el código. No comparta los resultados, en su lugar, haga un seguimiento de los resultados, realice una investigación independiente (mire el código) y determine la salud general de la base del código. A partir de esto, forme un plan de acción e intente remediar algunas de las áreas complejas del código.

Jon Raynor
fuente
3
Usted escribió: "Mi métrica personal es que si estoy mirando el código y es difícil de seguir o me hace sentir tonto, o siento que estoy desperdiciando muchos ciclos cerebrales para descubrir la lógica, entonces es un mal código". Cuanto más viejo me hago, más estoy de acuerdo con esto. Anteriormente pensé que este era un punto de vista pomposo. Sin embargo, ahora que he visto muchos procesos aparentemente complejos refactorizados en código elegante, me doy cuenta de que el código difícil casi siempre podría haberse escrito más claramente.
Ivan
Gracias Jon Las referencias que ha proporcionado son útiles. Para ser claros, el software tiene más de un año y los defectos no han desaparecido. Personalmente no he codificado en años, he sido un tipo de gerente durante demasiado tiempo y no técnico. Lectura Build IT y el libro hace eco de mis pensamientos. Es decir, el software de hardware que se ejecuta será un signo revelador de lo bien que se ha escrito. Muchas gracias de nuevo.
Tecnología nómada
Si bien los instintos acerca de si el código es bueno o malo puede ayudar a detectar el código incorrecto, no son métricas. Y los procesos automatizados para detectar "código incorrecto" basado en el formateo y el nombre de método / variable en realidad no hacen nada excepto hacer cumplir convenciones de nomenclatura consistentes dentro de un equipo (que si bien es bueno no garantiza ni mide la calidad real del código).
Jwenting
2
Además de la complejidad ciclomática, la profundidad de la herencia, el grado de acoplamiento de clases, y estoy seguro de que algunos otros, pueden ser excelentes indicadores de código sub-par. No se pueden usar únicamente como un indicador de calidad, pero pueden dar un buen punto de partida.
RubberDuck
3

Lo triste de las métricas es que puede terminar mejorando los valores resultantes de sus métricas, pero no la calidad que se pretende medir con ellas ...

En Visual Studio, hay una configuración para tratar las advertencias del compilador como errores. Ahora, algunas personas no entienden las advertencias y, para compilar el código, utilizarán trucos simples (como "advertencia de desactivación de pragma" o agregarán una palabra clave "nueva" a una función / propiedad que oculta un miembro no virtual de una base clase).

Si tiene acceso al código fuente, puede ejecutar un análisis de código estático. Para proyectos .Net, puede usar, por ejemplo, FxCop o ReSharper InspectCode. Cuando el equipo de desarrollo las utiliza correctamente, las herramientas ayudarán a mejorar la calidad. Pero, por supuesto, son posibles algunas "soluciones" para eliminar advertencias sin comprenderlas.

Podrías mirar las pruebas automatizadas / UnitTests: ¿qué tan buena es la cobertura del código? Pero la cobertura por sí sola no le dirá si las pruebas realmente verifican el código, o si solo se ejecutó una vez.

La lucha por la alta calidad es una actitud, que puede ser respaldada por muchas herramientas y sus métricas, pero las métricas sin la actitud de los desarrolladores no ayudan.

Bernhard Hiller
fuente
3

Una cosa que debe tener en cuenta además de recolectar una métrica como la inyección de defectos es averiguar la fuente de los defectos. Muchas veces está relacionado con la especificación.

Básicamente, es un error en la especificación, una ambigüedad en la especificación, dejada por los implantes para decidir o es un error en la implementación.

Un enfoque más cualitativo es preguntar si el software es útil. Si te fijas lo suficiente, puedes encontrar defectos en cualquier pieza de software. Sin embargo, si funciona lo suficientemente bien como para ganar dinero, entonces podría no ser tan malo.

Robert Baron
fuente
1
+1 Gran respuesta: no abordar la fuente de los errores es dejar la puerta abierta para más errores de la misma fuente
Robbie Dee
3

Abajo, no hay forma de saberlo.

Para la pregunta original (antes de la respuesta filosófica): ¿Qué se supone que debe hacer el producto y lo hace? La medición por conteo / densidad de defectos no es suficiente. No podría decir si se trataba de una biblioteca o una aplicación, qué tan grande es la base del código, qué tan grande es el dominio del problema, ni cuál es la gravedad de los defectos. Por ejemplo, no manejar uno de los 123 formatos de entrada podría ser un defecto trivial o un show stopper, dependiendo de la importancia del formato no manejado adecuadamente. Y mejor que nada es un alto estándar.

Supongo que hago para esta pregunta: hay una diferencia entre Código y Software. Defino software como lo que un cliente / usuario usa para resolver un problema, mientras que el código es el material de construcción del software.

El software solo se puede medir subjetivamente. Es decir, la métrica que importa para el software es si las personas lo usan para resolver un problema. Esta métrica depende del comportamiento de los demás, por lo tanto, es subjetiva. Nota: Para algunos problemas, una pieza de software puede ser bastante útil y, por lo tanto, se considera de alta calidad (Excel para cálculos), pero no un software de calidad para un problema diferente (Excel para reproducir archivos MP3).

El código puede (generalmente) medirse con métricas empíricas . Pero la interpretación no es 'sí / no' para la calidad, o incluso realmente en una escala de '0 a N'. Las métricas se comparan con un estándar. Por lo tanto, las métricas pueden encontrar áreas de preocupación definidas por el estándar, pero la ausencia de áreas de preocupación no es prueba de que este sea un código de calidad. Por ejemplo, métricas útiles: ¿se compila? No -> No calidad. Si -> ???. ¿Pasa la prueba de la unidad? ¿No? ¿Tal vez? (porque, ¿es el código de calidad de la prueba unitaria?), Sí -> ???.

Entonces, como lo demostró la Prueba de incompletitud de Godel para los axiomas de las matemáticas (es decir, existen enunciados matemáticos que no pueden probarse como verdaderos o falsos para ningún conjunto finito de axiomas), no creo que podamos responder realmente 'es esta cualidad ¿código?' para cada pieza de código Intuitivamente, es probable que haya un mapeo entre las métricas del software para responder a la calidad y los axiomas matemáticos para responder probablemente verdadero o falso.

Otra forma de hacer este argumento es entrar al lenguaje natural. William Shakespeare, Lewis Carroll y Mark Twain fueron todos escritores exitosos y amados por la calidad de sus escritos. Sin embargo, ¿qué estándar de gramática, vocabulario, estilo o voz podríamos aplicar que los calificara consistentemente más alto que los alumnos aleatorios de 12 ° grado? Y, si bien es posible crear alguna medida sintética para esos tres, ¿cómo calificaría el Libro de Juan (KJV), JRR Tolkien, Homer, Cervantes, etc.? Luego agregue Burroughs, Faulkner, Hemingway, Sylvia Plath, y así sucesivamente. La métrica no funcionará.

Kristian H
fuente
2

Lo mediría auditando (y buscando desviaciones en) su proceso.

Estaría buscando evidencia de un proceso para entregar que involucrara el control central de la fuente, el sistema de compilación central y un proceso que garantizara que el código se pruebe antes de la integración en la rama liberada.

También estaría buscando evidencia de cómo han modificado sus procesos en respuesta a situaciones donde los defectos han pasado por su proceso de liberación.

Si no pueden pasar este nivel de auditoría, entonces no puede esperar que entreguen versiones consistentes y confiables.

Si aprueban esta auditoría y continuamente mejoran su proceso, es probable que su consistencia de salida mejore con el tiempo.

Si esto no lo soluciona, entonces es probable que tengan un problema de arquitectura de código que hace que extender y probar su base de código actual sea problemático, en cuyo caso no hay buenas opciones.

Michael Shaw
fuente
Este es el tipo de respuesta que estaba buscando.
Tecnología nómada
0

Si está buscando mediciones completamente automatizadas, le recomiendo estas personas: Grupo de mejora de software

Es esencialmente un conjunto de varias métricas que se pueden extraer automáticamente del código fuente (como cobertura de prueba unitaria, tamaño de función, enredo de clases, duplicación, LOC, etc.). Esos valores se convierten en una calificación de 1-5 estrellas.

ingrese la descripción de la imagen aquí

También tienen un libro decente que describe todas sus métricas en la práctica que vale la pena leer: 'Creación de software mantenible' .

Eterno21
fuente