Come posso stimare la durata di una riga di codice?

Sto cercando di trovare un modo per analizzare la longevità del codice nei progetti open source: vale a dire da quanto tempo è attiva e in uso una specifica linea di codice.

Il mio pensiero attuale è che una linea della durata della vita del codice inizia quando viene impegnata per la prima volta e termina quando si verifica una delle seguenti condizioni:

• È modificato o eliminato,
• Escluso dalle build,
• Nessun codice all'interno della sua build viene mantenuto per un certo periodo di tempo (diciamo, un anno).

NOTA: come chiarimento sul motivo per cui una "modifica" viene conteggiata come "morte", le righe modificate verranno conteggiate come una "nuova" generazione o riga di codice. Inoltre, a meno che non ci sia un modo semplice per farlo, non ci sarebbe alcuna spiegazione della longevità di una discendenza o di una discendenza da un antenato.

Cos'altro determinerebbe una linea di durata del codice?

Andy Ozment ha esaminato OpenBSD nel 2006 con lo stesso tipo di domanda: latte o vino: la sicurezza del software migliora con l'età?

Potresti essere in grado di imparare dalla sua definizione. È anche un documento molto interessante, con anche una conclusione interessante, che non è stato incorporato nella tradizione di gestione del software:

In un periodo di 7,5 anni e quindici rilasci, il 62% delle 140 vulnerabilità segnalate in OpenBSD sono state fondamentali : presenti nel codice all'inizio dello studio.

Sono stati necessari più di due anni e mezzo per segnalare la prima metà di queste vulnerabilità fondamentali. Abbiamo scoperto che il 61% del codice sorgente nella versione finale studiata è fondamentale: rimane inalterato rispetto alla versione iniziale rilasciata 7,5 anni prima. È quindi probabile che il tasso di segnalazione delle vulnerabilità di base in OpenBSD continui a influenzare notevolmente il tasso complessivo di segnalazione delle vulnerabilità.

Abbiamo anche trovato prove statisticamente significative che il tasso di segnalazioni di vulnerabilità di base è diminuito durante il periodo di studio. Abbiamo utilizzato un modello di crescita dell'affidabilità per stimare che il 67,6% delle vulnerabilità nella versione di base era stato trovato. La stima del modello del numero previsto di vulnerabilità di base segnalate al giorno è diminuita da 0,051 all'inizio dello studio a 0,024.

Non credo che ci sia una risposta per questo. Dipende fortemente dal progetto. Alcuni sono più stabili nel corso degli anni, altri sono più volatili / refactored / in evoluzione nel corso degli anni.

Inoltre, è difficile da misurare. Una linea modificata è davvero la fine della sua durata? Che dire solo di un cambiamento estetico come riformattare la base di codice con schede o spazi? IMHO che non conta come base di codice rinnovata, ma sarebbe secondo i tuoi criteri.

Detto questo, penso che una buona parte dei LOC viva per sempre.

Il motivo è semplice: è molto più semplice aggiungere nuovo codice piuttosto che rimuoverne. Soprattutto quando il sistema è complesso e cresciuto negli anni. Quindi arriva rapidamente al punto in cui è "rischioso" rimuovere o modificare codice non banale. Potrebbe introdurre bug, interrompere la compatibilità, introdurre un effetto a farfalla di modifiche ... Quindi penso che più grande diventa la base di codice, più è vecchio, più i LOC rimarranno.

Inoltre, solo i buoni programmatori tendono a ripulire le basi di codice e ridurre le linee. Tutti gli altri tendono ad accumulare i LOC. E finora, questi ultimi stanno vincendo di gran lunga. ;)

L'eliminazione o l'esclusione di una riga di codice è sicuramente un'indicazione della fine della sua durata.

Riguardo alla modifica, vorrei porre questa domanda: questa affermazione produce un risultato diverso dopo la modifica?

Se la risposta è sì, allora direi che la precedente dichiarazione non è più disponibile, altrimenti la considererei comunque la continuazione della precedente.

Esempio di modifica del risultato:

if ( a && b )

per:

if ( a || b )

Esempio di continuare la durata della vita:

foo.bar( baz );

per:

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