Domanda

Ogni moderno sistema di controllo del codice sorgente può scomporre e analizzare la storia di un programma. Ci sono molti strumenti per analizzare staticamente e dinamicamente il codice. Che tipo di formula matematica mi avrebbe permesso di integrare la quantità di attività in un file insieme al numero di implementazioni di questo software? Stiamo scoprendo che, anche se un programma completa di tutti i suoi test di unità, richiede più lavoro di quanto ci si aspetterebbe in fase di aggiornamento. Una misura di questo tipo dovrebbe essere possibile, ma sedersi e pensare anche le sue unità mi ha messo in difficoltà.

Aggiornamento: Se qualcosa viene inviato ad una macchina di prova ho potuto vedere la marcatura meno marcio. Se qualcosa viene inviato a tutte le caselle di test ho potuto vedere che ottenere un marcatore fresca. Se qualcosa va alla produzione ho potuto dare un cenno del capo e ridurre la sua bitrot punteggio. Se c'è un sacco di attività all'interno dei propri file e non è mai da nessuna parte viene inviato lo farei ding il crap fuori di esso. Non concentrarsi sul codice per scontato che tutti i dati che mi serve è a portata di mano.

Che tipo di commettere analisi (commettere commenti (di cui sotto) o il tempo tra commit) sono i dati equo applicare?

Aggiornamento: Credo che l'analisi dimensionale potrebbe probabilmente essere solo in base all'età. Relativo a che è un po 'più difficile. Vecchio codice è marcio. L'età media di ogni riga di codice è ancora semplicemente una misura di tempo. Fa un modulo fonte più grande marcire più velocemente di uno più piccolo, più complesso?

Aggiorna la copertura di codice è misurata in linee. Codice eseguito spesso deve essere per definizione meno marcio di codice mai eseguito. Per misurare con precisione bitrot si avrebbe bisogno di analisi della copertura di agire come un ammortizzatore.

È stato utile?

Soluzione 5

La risposta ovvia è no. Bitrot non ha dimensioni accettate.

Altri suggerimenti

Molto interessante linea di pensiero!

In primo luogo, ciò che è bitrot? Il rel="nofollow articolo Software Rot su wikipedia raccoglie alcuni punti:

  • cambiamento Ambiente: cambiamenti nel runtime
  • Il codice non utilizzato: cambiamenti nei modelli di utilizzo
  • Codice Raramente aggiornato: cambiamenti attraverso la manutenzione
  • Refactoring: un modo per arginare bitrot

Legge di Moore , delta(CPU)/delta(t) è un fattore costante due ogni 18 a 24 mesi . Poiché l'ambiente contiene più di CPU, presumo che questa forma solo una debole limite inferiore effettivo cambiamento nell'ambiente. Unità: OPS / $ / s, il cambiamento in Operations Per Second per dollaro nel corso del tempo

delta(users)/delta(t) è più difficile da quantificare, ma la prova della frequenza delle occorrenze delle parole "Età della Conoscenza" nelle notizie, direi che le aspettative degli utenti crescono in modo esponenziale anche. Osservando lo sviluppo dell'economia di base $/flops ci dice che l'offerta sta crescendo più rapidamente della domanda, dando la legge di Moore come limite superiore del cambiamento dell'utente. Userò punti funzione ( "quantità di funzionalità di business un sistema informativo fornisce ad un utente" ) come misura di requisiti. Unità: FP / s, il cambiamento in Function Point richiesti nel tempo

delta(maintenance)/delta(t) dipende totalmente l'organizzazione e di solito è abbastanza alto immediatamente prima di un rilascio, quando soluzioni rapide sono spinti attraverso e quando l'integrazione di grandi cambiamenti. Modifiche a varie misure come SLOC , complessità ciclomatica o punti funzione implementata nel corso del tempo può essere utilizzato come uno stand-in qui. Un'altra possibilità sarebbe quella bug-churn nel sistema di bigliettazione, se disponibile. Starò con punti funzione implementata nel corso del tempo. Unità = FP / s, il cambiamento in punti funzione implementata nel tempo

delta(refactoring)/delta(t) può essere misurata come tempo trascorso non implementazione di nuove funzionalità. Unità = 1, il tempo trascorso refactoring nel tempo

Quindi bitrot sarebbe

             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 un'unità combinata di OPS/$/s * FP/s * FP/s = (OPS*FP²) / ($*s³).

Questa è ovviamente solo una notazione pseudo-matematica molto forzata di ciò che l'articolo di Wikipedia ha già detto: bitrot deriva da cambiamenti nell'ambiente, i cambiamenti nelle esigenze degli utenti e le modifiche al codice, mentre è mitigato dal trascorrere del tempo il refactoring. Ogni organizzazione dovrà decidere da sé come misurare questi cambiamenti, ho solo dare limiti molto generali.

Non sono d'accordo con Charlie: minor refactoring del codice sorgente può provocare molto grande distanze di Hamming , e non fornisce una buona misura del grado in cui il codice è stato logicamente modificato.

Vorrei prendere in considerazione guardando la lunghezza del commit commenti. Per un dato programmatore, un commento relativamente lungo commettere indica in genere che hanno fatto un cambiamento significativo al codice.

Come per il più semplice possibile risposta?

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

Se un file non è stato distribuito (sia alla produzione o ad una macchina di prova) per un lungo periodo di tempo, può essere sincronizzato con la "realtà". L'ambiente può essere cambiato, e anche se il file non è stato modificato, non può più funzionare. In modo che mi sembra essere una formula semplice e preciso. Perchè renderlo più complesso di quello? serie di modifiche che coinvolgono sembra aggiungere unica incertezza. Se un file è stato modificato di recente, significa che è stato aggiornato per riflettere un cambiamento nell'ambiente (che lo rende "meno marcio"), o sono state aggiunte nuove funzionalità (aumentando il rischio di errori, e così rendendo " più marcio ")? Le modifiche ad un file potrebbe significare qualsiasi cosa.

L'unico fattore inequivocabile mi viene in mente è "quanto tempo come è stato dall'ultima volta che abbiamo verificato che il file ha lavorato ?"

Mi viene in mente Evidence Based Scheduling . Vieni con un set di metriche ragionevoli per indicare bitrot (sia il suo valore reale e quanto è stato ridotto di una particolare modifica). Quindi determinare come precisa si basano sul tempo speso in seguito. Venendo con i numeri e le regole per questo probabilmente è complicato.

Inversa proporzione del numero di unit test per le linee totali di codice?

pensare a due possibili misure: edit differenze, come Hamming o Wagner a distanza; e le informazioni teoria dell'entropia.

Se siete veramente interessati a scavare in questo, v'è una certa ricerca là fuori. Stavo guardando i concetti da un articolo che ha esaminato l'effetto di Struttura organizzativa sulla Qualità del Software qualche tempo fa. Ho finito per il deposito delle idee via nella parte posteriore della mia testa, ma si potrebbe trovare illuminante.

Dal momento che non ci preoccupiamo di codice che funziona, mi piacerebbe guardare il numero di modifiche apportate a un file (non quanto grande i cambiamenti sono stati, quanto spesso un file viene modificato) e quanti errori sono stati fissati dal tali modifiche più il numero di bug aperti che vengono registrati contro il file. Il risultato dovrebbe essere un numero che diventa più grande il più marcio di un file.

I file che cambiano spesso (config, ecc), mentre non fissare un grosso non verranno visualizzati perché la parte bug dell'equazione sarà basso. File con un sacco di bug aperti apparirà così come i file in cui i cambiamenti spesso portano a nuovi bug. I cambiamenti * correzioni di bug numero dovrebbe erodere nel tempo (perché non ci preoccupiamo per i vecchi punti caldi).

Il mio unico problema con i test di copertura del codice e unit è che i test unità di prova solo quello che sono stati originariamente progettati per testare, e che, per definizione, sono il codice e incline allo stesso software-rot funzionale che affligge il codice regolare. (Sono buoni solo per quello che sono scritti per, e dopo un po ', questo non è sufficiente)

Ma i test di unità di alta qualità, ovviamente, fornire una certa protezione.

Quindi, questi sono i miei fattori importanti per rot software:

  1. Numero di punti di interfaccia dati esterni (extDataIntfPts)
    • qualità del trattamento dei dati / errori, test di unità (codeQuality)
    • La dipendenza da implementazioni di base, come OS / VM. (OsDep)
    • Numero di punto dell'interfaccia attuazione esterno come plugin. (ExtIntfPts)
    • Complessità del codice / volume semplice di codice (linesOfCode)

Come sistema vive in produzione, è esposto ad una maggiore varietà di ingressi dati del gruppo di dati che ha raccolto cresce. Questo per definizione espone il codebase di un maggior numero di casi limite e sequenze.

Questo può essere mitigato dalla qualità del trattamento dei dati, la gestione degli errori, e test di unità.

C'è anche i bersagli in movimento dell'ambiente sottostante che il sistema opera in. Un modo per moderare questo è quello di mettere l'applicazione in una macchina virtuale.

Se il sistema implementa plugin, ho potuto vedere il codice di base di fronte a una maggiore probabilità di fallimento come si sviluppano più plugin.

codice complesso! = Codice elegante. Se è elegante, probabilmente è semplice. Io vado con il semplice punto qui che il codice c'è più, il meno probabile è che sia ben testato, ma suppongo che potrebbe essere girato intorno.

Quindi, ecco la mia equazione:

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

A giudicare codeQuality probabilmente comportare la metrica di ciò che la copertura del codice nei test di unità è. È possibile eseguire un programma di analisi statica contro di essa per determinare potenziali bug e che sarebbe probabilmente un po 'di aiuto pure. Voglio dire, ad un certo punto, è davvero difficile segnare perché il codice multi-threading deve essere ponderata molto più pesante di un POJO. E sì, il refactoring dovrebbe essere calcolato in, ma solo dove ci sono evidenze di marciume software.

Alla fine, si tratta di una pseudo-scienza. Ecco il mio contributo alla pseudo-scienza.

Patrimonio bitrot (non software rot) ha dimensioni di volume fisico di archiviazione * tempo.

bitrot è causato dal decadimento radioattivo di impurezze nel supporto di memorizzazione.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top