¿Cómo puedo estimar la vida útil de una línea de código?

Estoy tratando de encontrar una manera de analizar la longevidad del código en proyectos de código abierto: es decir, cuánto tiempo una línea de código específica está activa y en uso.

Mi opinión actual es que la vida útil de una línea de código comienza cuando se confirma por primera vez y termina cuando ocurre una de las siguientes situaciones:

• Está editado o eliminado,
• Excluido de las compilaciones,
• Ningún código dentro de su compilación se mantiene durante un período de tiempo (por ejemplo, un año).

NOTA: Como aclaración sobre por qué una "edición" se cuenta como "muerte", las líneas editadas se contarían como una "nueva" generación o línea de código. Además, a menos que haya una manera fácil de hacer esto, no se tendrá en cuenta la longevidad de un linaje o el descenso de un antepasado.

¿Qué más determinaría la vida útil de una línea de código?

Andy Ozment miró a OpenBSD en 2006 con el mismo tipo de pregunta: leche o vino: ¿la seguridad del software mejora con la edad?

Es posible que pueda aprender de su definición. También es un documento muy interesante, con una conclusión interesante, una que no se ha incorporado en la tradición de gestión de software:

Durante un período de 7,5 años y quince lanzamientos, el 62% de las 140 vulnerabilidades reportadas en OpenBSD fueron fundamentales : presentes en el código al comienzo del estudio.

Tomó más de dos años y medio para que se informara la primera mitad de estas vulnerabilidades fundamentales. Descubrimos que el 61% del código fuente en la versión final estudiada es fundamental: permanece inalterado de la versión inicial lanzada 7.5 años antes. Por lo tanto, es probable que la tasa de informes de vulnerabilidades fundamentales en OpenBSD continúe influyendo en gran medida en la tasa general de informes de vulnerabilidades.

También encontramos evidencia estadísticamente significativa de que la tasa de informes de vulnerabilidad fundamental disminuyó durante el período de estudio. Utilizamos un modelo de crecimiento de confiabilidad para estimar que se había encontrado el 67.6% de las vulnerabilidades en la versión básica. La estimación del modelo del número esperado de vulnerabilidades fundamentales reportadas por día disminuyó de 0.051 al inicio del estudio a 0.024.

No creo que haya una respuesta para eso. Es altamente dependiente del proyecto. Algunos son más estables a lo largo de los años, otros son más volátiles / refactorizados / evolucionados a lo largo de los años.

Además, es difícil de medir. ¿Es realmente una línea editada el final de su vida útil? ¿Qué pasa con solo un cambio cosmético como formatear el código base con pestañas o espacios? En mi humilde opinión, eso no cuenta como código base renovado, pero lo haría de acuerdo con sus criterios.

Dicho esto, creo que una buena parte de los LOC viven para siempre.

La razón es simple: es mucho más fácil agregar un nuevo código en lugar de eliminar algunos. Especialmente cuando el sistema es complejo y crece con los años. Luego, llega rápidamente a un punto en el que es "riesgoso" eliminar o cambiar el código no trivial. Podría introducir errores, romper la compatibilidad, introducir un efecto mariposa de los cambios ... Así que creo que cuanto más grande sea la base de código, cuanto más antigua sea, más se quedarán los LOC.

Además, solo los buenos programadores tienden a limpiar las bases de código y reducir las líneas. Todos los demás tienden a acumular los LOC. Y hasta ahora, estos últimos están ganando con diferencia. ;)

Eliminar o excluir una línea de código definitivamente es una indicación del final de su vida útil.

Al regrabar la edición, haría esta pregunta: ¿Esta declaración produce un resultado diferente después de la edición?

Si la respuesta es sí, entonces diría que la declaración anterior ya no está disponible, de lo contrario aún la consideraría como la continuación de la declaración anterior.

Ejemplo de cambiar el resultado:

if ( a && b )

a:

if ( a || b )

Ejemplo de continuar la vida útil:

foo.bar( baz );

a:

foo.prototype.bar.call( this, baz );