calcolare quanto tempo è possibile risparmiare attraverso la stima del codice scritto in un anno

sto cercando figure reali ed esperienze, si prega di non prendere questo troppo soggettivo:calcolare quanto tempo è possibile risparmiare attraverso la stima del codice scritto in un anno

Mentre cerca di qualcosa di diverso, I happened on an interesting statement, che in parte è così formulato:

[...] la media nazionale è di 9.000 righe di codice all'anno per persona [...]

. 210

Scrivo molto codice, ma non a tempo pieno. Quando guardo indietro ai miei progetti dell'anno scorso e faccio un conteggio (molto approssimativo) (contando solo le righe di codice, senza commenti o linee bianche), arrivo a circa 19.000 per un anno che lo trasformano in un progetto. Se riesco ad automatizzare parti di questo, posso dedurre il profitto in tempo e denaro.

Per la stima del risparmio di tempo per i progetti più grandi, ho bisogno di medie. Quante linee di codice l'uomo scrive in un anno, in media, in C# (o altra lingua di scelta)? E, guardando la tua situazione, considereresti che il tuo codice scritto a mano potrebbe essere (parzialmente) automatizzato e con quale guadagno?

fonte

2010-01-21 Abel

10 righe di assemblaggio non corrispondono a 10 righe di C non corrispondono a 10 righe di Ruby. –

Solo una piccola osservazione: qualcuno sapeva che il debacle OS/2 vs Windows (rottura IBM vs Microsoft) era parzialmente il risultato di IBM che misurava la produttività tramite linee di codice, cosa che frustrava i programmatori di Microsoft? http://en.wikipedia.org/wiki/OS/2#Breakup – Abel

xkcd obbligatorio: [1] (https://xkcd.com/1205/) [2] (https://xkcd.com/1319/) [3] (https://xkcd.com/1445/). – user4157124

Innanzitutto, le righe di codice scritte non sono correlate con la produttività effettiva. Almeno secondo me, se vuoi misurare e/o stimare la produttività, i punti di funzione sono una misurazione più efficace. In secondo luogo, quando una metrica varia su un ampio intervallo, la media generalmente significa molto poco. In un caso come questo, una media geometrica generalmente significa più di una media aritmetica, ma senza (almeno) qualcosa sulla varianza/deviazione standard, non significa ancora molto.

Vorrei anche notare che ci sono alcuni modelli abbastanza sofisticati che sono stati sottoposti a ricerche sostanziali e persino misurati rispetto a progetti reali per avere almeno qualche idea che i loro risultati siano in correlazione con la realtà.Ad esempio, il modello COCOMO II generalmente produce risultati molto migliori rispetto all'utilizzo di righe di codice per unità di tempo. C'è almeno uno free online implementation (Modifica: guardandolo, questo ora consente la modellazione basata su LoC o sul punto di funzione). Ci sono anche strumenti come SoftStar e Function Point Modeler) che combinano un modello simile a COCOMO con punti funzione per ottenere ciò che appare (almeno per me) come risultati abbastanza solidi.

fonte

2010-01-21 22:49:36

Molto interessante e ben scritto. Grazie.Mi piace in particolare il puntatore ai Function Points, di cui avevo bisogno quando PM'ing (parte di) un enorme progetto del governo olandese, dove tutto era misurato in FP (e funzionava un po ': se aggiungevi un fattore 2.4 ad esso, ma questa è una lunga storia ... ;-) – Abel

@Abel: un fattore di 2,4 è in realtà un bel po 'meglio di quanto la maggior parte dei metodi possa anche sperare. Se provi a basare le cose su linee di codice, generalmente sarai fortunato ad avvicinarti molto di più di un fattore 5, ed essere fuori da un fattore 10 non è poi così raro. –

Accettare la tua risposta in quanto è l'unica che riguarda veramente l'uso di linee di codice come misura per la pianificazione del progetto o la valutazione del guadagno di miglioramento. Capisco che la pratica non è necessariamente buona e può anche essere cattiva. In situazioni in cui si deve usarlo o dove si devono ancora inventare metodi migliori, conoscerne i difetti è un grande beneficio e un male necessario. – Abel

18000 equivarrebbe a circa 36 righe di codice al giorno.

Con solo 36 righe di codice al giorno, qual è il problema? Il problema è il debug e la riscrittura del codice.

NULLA che tu possa fare per automatizzare la codifica ti farà accelerare - in effetti, tutto ciò che puoi automatizzare probabilmente non dovrebbe essere codificato perché se stai automatizzando la digitazione di alcuni pattern nel tuo codice, dovrebbe essere scomposto.

Dove è possibile risparmiare tempo è fare più attenzione a come si codifica. Trasforma il tuo progetto in QA un po 'più velocemente: codifica in un linguaggio e un codice più espliciti e tipicamente più chiari.

Anche rendendo i dati del codice guidati e pienamente fattorizzati laddove possibile, sebbene riduca il LOC che spedite, renderà la vita di tutti più facile e la spedizione del progetto più veloce.

Non MAI automatizzare l'immissione del codice: se puoi, lo stai facendo male!

Un altro modo per pensarci: ogni riga di codice che si crea deve essere sottoposta a debugging e manutenzione. Perché stai cercando di trovare un modo per dare a tutti PIÙ lavoro quando potresti semplicemente creare codice completamente fattorizzato (l'input di codice completamente fattorizzato non può essere automatizzato - praticamente per definizione).

fonte

2010-01-21 22:20:10

(Ho trascorso solo pochi giorni/mese di programmazione, la media giornaliera è diversa) Penso che tu abbia punti molto interessanti contro l'automazione. L'utilizzo del software di auto-generazione di mappatura dei dati mi consente di risparmiare scrittura di POCO e classi generiche (architettura S # arp). L'implementazione di INotifyPropertyChanged per ogni proprietà potrebbe facilmente essere automatizzata. Andrew Hunt in Pragmatic Programmer? Dice "automatizza dove puoi". Una buona generazione automatica del codice dovrebbe far risparmiare tempo, ma dovrebbe essere testata di per sé. – Abel

Btw, a quanto pare ero un po 'assonnato ieri, o tu: 19000/36 = 527 giorni? ;-) – Abel

Sì, penso che la matematica sembra davvero spenta. Quando divido il LOC in un prodotto di spedizione dalle ore-uomo spesi su di esso tendo a ottenere qualcosa nella zona di 1-4 linee al giorno. In ogni caso, la rimozione di boilerplate invece di automatizzarla dovrebbe essere l'obiettivo primario: è la differenza tra danneggiare il tuo progetto e aiutarlo. Sono quasi sempre riuscito a trovare un modo per sbarazzarmene - ad esempio non mi piacciono molto gli oggetti di accesso e li sostituirò con strutture dati o qualcosa di simile. Cerco continuamente pratiche che mi permettano di scrivere codice fattorizzato. –

Questo è il tipo di metrica di cui si parla nello Mythical Man Month. La stima dei progetti in Man-Days/Months/Years o il conteggio delle righe di codice come un metirc di produttività garantisce l'inesattezza nel reporting.

fonte

2010-01-21 22:23:49

Ah, il mio libro preferito! Sì, continuo ad amare MMM. Qualsiasi rapporto, non solo per esso, ha un fattore di inesattezza. Conoscere il fattore aiuta a interpretare bene il rapporto. – Abel

-2

Questa è una domanda piuttosto negativa, in realtà. Anche i devoti dello SLOC ammetteranno che le stime di produttività SLOC sono valide solo in ambienti simili. Non solo varia dal linguaggio di programmazione, ma dall'industria, dall'ambiente di sviluppo, dall'applicazione, ecc.

Nella misura in cui i numeri SLOC valgono qualcosa, è solo all'interno dello stesso team di sviluppo che lavora a progetti simili.

fonte

2010-01-21 23:22:05

Non sarei d'accordo nel chiamare una domanda BS nel momento in cui la risposta è "non farlo perché ...". Un buon consiglio è spesso benvenuto. La prima volta che ho riparato la gomma, mio padre ha ricevuto molte domande da parte mia. Lieto, ha risposto loro e sono stato in grado di imparare. Non conoscevo SLOC, ho imparato qualcosa. – Abel

Ciò che è peggio, la produttività non è necessariamente direttamente correlata a LOC. Tutti hanno visto una funzione di cinquanta linee che qualcuno ha scritto perché non potevano vedere la semplice soluzione a cinque linee. –

Credo che la tariffa per LOC dipenda molto dallo technical debt nel progetto.

Ho un progetto (SQL) che è 27KLOC (più 4K in più per il supporto). Lavorando su questo codice, più di 7 mesi, ho aggiunto 3K net new LOC al progetto, con circa 14KLOC scritto solo per test di scarto (test per isolare le anomalie, non i test unitari).

A seconda di come si misura, scrivo 29KLOC/anno ((3K + 14K)/7 mesi * 12 mesi) ma produco solo 5KLOC/anno (3K/7 mesi * 12 mesi).

Guardando il codice (27KLOC) come debito, abbiamo il codice che genera il 7% (2KLOC) nel codice usa e getta mensile o l'88% (24KLOC) all'anno.

Supponendo che possa continuare a produrre un intero 29KLOC/anno, e supponendo che il costo del mantenimento del codice rimanga all'88% annuo, il mio limite di progetto personale è di 33K linee di codice. Oltre a ciò, passerò tutto il mio tempo a pagare gli interessi sul mio debito tecnico, scrivendo il codice "usa e getta" e producendo lo zero netto LOC.

Fortunato che l'ultimo 3KLOC fosse un refactoring, che dovrebbe ridurre il mio tasso di interesse.

fonte

2010-08-24 03:25:09

+1 analisi interessante, aggiunge qualcosa alla discussione e il mio pensiero sull'argomento, grazie! – Abel

calcolare quanto tempo è possibile risparmiare attraverso la stima del codice scritto in un anno

risposta

Problemi correlati