Qué bitrot tiene ningún dimensiones aceptadas?

https://stackoverflow.com/questions/715840

23-08-2019
|

Pregunta

Cada sistema de control de código fuente moderna puede examinar minuciosamente la historia de un programa. Hay muchas herramientas para analizar estática y dinámicamente código. ¿Qué tipo de fórmula matemática me permitiera integrar la cantidad de actividad en un archivo junto con el número de despliegues de que el software? Estamos encontrando que incluso si un programa se completa la totalidad de sus pruebas de unidad, se requiere más trabajo de lo que cabría esperar en el tiempo de actualización. Una medida de este tipo debe ser posible, pero sentarse y pensar en sus unidades incluso me ha dejado perplejos.

Actualización: Si algo se envía a una máquina de prueba pude ver marcándolo menos podrido. Si algo se envía a todas las cajas de ensayo pude ver que conseguir un marcador fresco. Si algo va a la producción pudiera dar una inclinación de cabeza y reducir su bitrot puntuación. Si hay una gran cantidad de actividad dentro de sus archivos y nunca se envía en cualquier lugar que lo haría ding la basura fuera de ella. No se centre en el código asume que los datos que necesito está a la mano.

¿Qué tipo de análisis cometer (commit comentarios (mencionados a continuación) o el tiempo entre confirmaciones) se aplican a los datos justos?

Actualización: Creo que el análisis dimensional podría probablemente sólo se basa en la edad. En relación con esto es un poco más difícil. código antiguo está podrido. La edad promedio de cada línea de código todavía es simplemente una medida de tiempo. Hace un módulo de fuente más grande se pudre más rápido que uno más pequeño, más complejo?

Actualizar Cobertura de código se mide en líneas. Código que se ejecuta a menudo por definición, debe ser menos podrida que el código nunca se ejecutó. Para medir con precisión bitrot que se necesita análisis de la cobertura de actuar como un amortiguador.

Solución 5

La respuesta obvia es no. BItrot no tiene ningún dimensiones aceptadas.

Otros consejos

tren muy interesante de pensamiento!

En primer lugar, ¿qué es bitrot? El rel="nofollow artículo Software Rot en Wikipedia recoge algunos puntos:

cambiar el medio ambiente: los cambios en el tiempo de ejecución
código no utilizado: los cambios en los patrones de uso
código Rara vez actualizado: cambios a través de mantenimiento
Refactoring: una manera de detener bitrot

la Ley de Moore , delta(CPU)/delta(t) es un factor constante dos cada 18 a 24 meses . Dado que el entorno contiene más de la CPU, yo supongo que esta forma sólo se limitan un muy débil inferior sobre el cambio real en el medio ambiente. Unidad: OPS / $ / s, cambio en operaciones por segundo por dólar a través del tiempo

delta(users)/delta(t) es más difícil de cuantificar, pero la evidencia en la frecuencia de apariciones de las palabras "era del conocimiento" en las noticias, yo diría que las expectativas de los usuarios crecen exponencialmente también. Al observar el desarrollo de la economía básica $/flops nos dice que la oferta está creciendo más rápido que la demanda, dando a la Ley de Moore como límite superior de cambio de usuario. Voy a usar puntos de función ( "cantidad de funcionalidad de negocio un sistema de información proporciona a un usuario" ) como una medida de las necesidades. Unidad: FP / s, el cambio en los puntos de función requeridos con el tiempo

delta(maintenance)/delta(t) depende totalmente de la organización y suele ser bastante alta inmediatamente antes de un lanzamiento, soluciones rápidas cuando son empujados a través y en la integración de grandes cambios. Los cambios en diversas medidas como SLOC , ciclomática Complejidad o puntos de función implementadas con el tiempo se puede utilizar como un sustituto de aquí. Otra posibilidad sería bug-rotación en el sistema de venta de entradas, si está disponible. Me quedo con los puntos de función implementadas a través del tiempo. Unidad = PF / s, el cambio en los puntos de función implementadas a través del tiempo

delta(refactoring)/delta(t) se puede medir como el tiempo dedicado no aplicación de nuevas características. Unidad = 1, refactorización tiempo pasado con el tiempo

Así bitrot sería

             d(env)     d(users)     d(maint)        d(t)
bitrot(t) = -------- * ---------- * ---------- * ----------------
              d(t)        d(t)        d(t)        d(refactoring)

             d(env) * d(users) * d(maint)
          = ------------------------------
                d(t)² * d(refactoring)

con una unidad combinada de OPS/$/s * FP/s * FP/s = (OPS*FP²) / ($*s³).

Esto es, por supuesto, sólo una notación pseudo-matemática muy forzada de lo que el artículo de Wikipedia ya se dijo: surge bitrot de los cambios en el medio ambiente, los cambios en los requisitos y cambios en el código de los usuarios, al tiempo que se mitiga por el tiempo de pasar en refactorización. Cada organización tendrá que decidir por sí mismo cómo medir esos cambios, que solo le daría límites muy generales.

No estoy de acuerdo con Charlie: menor refactorización de código fuente puede dar lugar a muy grande distancias Hamming , y no proporciona una buena medida del grado en que el código ha sido modificado lógicamente.

Me gustaría considerar la búsqueda de la longitud de cometer los comentarios. Para un programador dado, un comentario relativamente largo comprometerse por lo general indica que han hecho un cambio significativo en el código.

¿Qué hay de la más simple posible respuesta?

foreach (file in source control){
  file.RotLevel = (Time.Now - file.LastTestedOrDeployed)
}

Si un archivo no se ha desplegado (ya sea para la producción o en una máquina de prueba) durante mucho tiempo, puede estar fuera de sincronía con la "realidad". El entorno puede haber cambiado, e incluso si el archivo no se ha cambiado, ya no puede trabajar. Así que me parece ser una fórmula sencilla y precisa. ¿Por qué hacer que sea más complejo que eso? Que implica varios cambios parece añadir única incertidumbre. Si un archivo ha sido modificado recientemente, quiere decir que ha sido actualizado para reflejar un cambio en el medio ambiente (lo que hace que sea "menos podrido"), o cuando se añaden nuevas características (aumentando el riesgo de errores, y así por lo que es " más podrido ")? Las modificaciones a un archivo podría significar cualquier cosa.

El único factor inequívoco que puedo pensar es "¿cuánto tiempo, ya que ha pasado desde la última vez comprobado que el archivo trabajó ?"

Me acuerdo de Evidencia Planificación basada en . Vamos con un conjunto de métricas razonables para indicar bitrot (tanto su valor real y cuánto se redujo en un cambio en particular). A continuación, determinar la forma precisa que se basan en el tiempo pasado después. El subir con los números y las reglas de esto es probablemente complicado.

Inverse proporción de número de pruebas de unidad para el total de líneas de código?

pensar en dos posibles medidas: editar diferencias, como Hamming o Wagner distancia; y la teoría de la información entropía.

Si está realmente interesado en la excavación en esto, hay algunas investigaciones que hay. Yo estaba buscando en los conceptos de un artículo que examinó el efecto de rel="nofollow Estructura organizacional en Calidad de Software hace un tiempo. Terminé la presentación de las ideas de distancia, en la parte posterior de la cabeza, pero le puede resultar esclarecedor.

Dado que no se preocupan por el código que funciona, me vería en el número de cambios realizados en un archivo (no tan grande fueron los cambios, con qué frecuencia un archivo se cambia) y cuántos errores fueron corregidos por los cambios más el número de errores abiertos que están conectados con el archivo. El resultado debe ser un número que se hace más grande cuanto más podrida es un archivo.

Los archivos que cambian a menudo (config, etc), mientras que no se fija el grande no se mostrará debido a que la parte de errores de la ecuación será baja. Archivo con un montón de errores abiertos se mostrará al igual que los archivos donde los cambios a menudo conducen a nuevos errores. Los cambios * Corrección de errores número debe erosionarse con el tiempo (debido a que no se preocupan por los viejos puntos de acceso).

Mi único problema con las pruebas de cobertura de código y la unidad es que las pruebas de unidad única prueba lo que fueron diseñados originalmente para probar, y que, por definición, son de código y propensos a la pudrición mismo software-funcional que afecta a código regular. (Que sólo son buenos para lo que están escritas para, y después de un tiempo, eso no es suficiente)

Sin embargo, las pruebas unitarias de alta calidad, obviamente, proporcionar algún tipo de protección.

Así que estos son mis factores importantes para la pudrición de software:

Número de puntos de interfaz de datos externos (extDataIntfPts)
- Calidad de manejo de datos / error, pruebas de unidad (codeQuality)
- La dependencia de las implementaciones subyacentes, como OS / VM. (OsDep)
- Número de punto de interfaz aplicación externa tal como plugins. (ExtIntfPts)
- Complejidad de código / volumen simple de código (linesOfCode)

Como sistema vive en la producción, se expone a una mayor variedad de entradas de datos como el conjunto de datos que ha recogido crece. Esto, por definición, expone el código base para un mayor número de casos de borde y secuencias.

Esto puede ser mitigado por la calidad del tratamiento de datos, tratamiento de errores, y pruebas de unidad.

Hay también los blancos móviles del entorno subyacente de que el sistema funciona en. Una forma de moderar esto es poner la aplicación en una máquina virtual.

Si el sistema implementa plugins, pude ver el código base de cara a una mayor probabilidad de fracaso como se desarrollan más plugins.

código complejo! = Código elegante. Si es elegante, es probable que sea sencillo. Voy con el punto simple aquí que el código sea más hay, menos probable es que está bien probado, pero supongo que podría dar la vuelta.

Por lo tanto, aquí está mi ecuación:

bitrot=((linesofcode/codeQuality)*(extDataInfPts+(osDep/change)+extIntfPts)*numberOfSecondsDeployed)

A juzgar codeQuality probablemente implicaría la métrica de lo que la cobertura de código en las pruebas unitarias es. Se podría ejecutar un programa de análisis estático contra ella para determinar los errores potenciales y que probablemente sería un poco de ayuda también. Es decir, en algún momento, es realmente difícil de conseguir porque el código multi-threading debe ser ponderado mucho más pesado que un POJO. Y sí, la refactorización debe ser figurado en, pero sólo cuando hay evidencias de la podredumbre de software.

Al final, se trata de una pseudo-ciencia. Esta es mi contribución a la pseudo-ciencia.

bitrot real (no la podredumbre de software) tiene unas dimensiones de volumen físico de almacenamiento * tiempo.

Bitrot es causada por la desintegración radiactiva de impurezas en el medio de almacenamiento.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow