Mythical man month 10 righe per day developer - quanto sono vicini i grandi progetti? [chiuso]

Tutti dicono sempre che possono battere le "10 righe per sviluppatore al giorno" dal "Mese dell'uomo mitico", e iniziando un progetto, di solito riesco a ottenere un paio di centinaia di righe in un giorno.

Ma per il mio precedente datore di lavoro, tutti gli sviluppatori erano molto acuti, ma si trattava di un grande progetto, oltre un milione di righe di codice, con requisiti di certificazione molto onerosi e interfacciamento con altri progetti da più milioni di linee. Ad un certo punto, come esercizio di curiosità, ho tracciato linee di codice nel prodotto di spedizione nel mio gruppo (senza contare gli strumenti che abbiamo sviluppato), e abbastanza sicuro, in modo incrementale, è arrivato a circa 12 linee di guadagno netto per sviluppatore al giorno. Senza contare le modifiche, il codice di test o il fatto che gli sviluppatori non lavorassero sul codice di progetto effettivo ogni giorno.

Come stanno le altre persone? E che tipo di requisiti devi affrontare (immagino sia un fattore)?

Penso che il numero di linee aggiunte sia fortemente dipendente dallo stato del progetto, il tasso di aggiunta a un nuovo progetto sarà molto più alto di quello di un progetto iniziale.

Il lavoro è diverso tra i due: in un grande progetto di solito passi la maggior parte del tempo a capire le relazioni tra le parti, e solo una piccola parte per cambiare / aggiungere effettivamente. mentre in un nuovo progetto - per lo più scrivi ... fino a quando non è abbastanza grande e il tasso diminuisce.

In uno dei miei progetti attuali, in alcuni moduli, sono orgoglioso di aver contribuito con un numero di righe negative alla base di codice. Identificare quali aree del codice hanno sviluppato una complessità non necessaria e possono essere semplificate con un design più pulito e più chiaro è un'abilità utile.

Naturalmente alcuni problemi sono intrinsecamente complessi e richiedono soluzioni complesse, ma sulla maggior parte dei progetti di grandi dimensioni aree che hanno avuto una definizione mal definita o che cambiano i requisiti tendono ad avere soluzioni troppo complesse con un numero maggiore di problemi per linea.

Dato un problema da risolvere, preferisco di gran lunga la soluzione che riduce il conteggio delle righe. Certo, all'inizio di un piccolo progetto posso generare molte più di dieci righe di codice al giorno, ma tendo a non pensare alla quantità di codice che ho scritto, solo a quello che fa e quanto bene lo fa. Certamente non mirerei a battere dieci linee al giorno o considerarlo un risultato per farlo.

Mi piace questa citazione:

Se desideriamo contare le righe di codice, non dovremmo considerarle come "linee prodotte" ma come "linee spese". - Edsger Dijkstra

Alcune volte hai contribuito di più rimuovendo il codice piuttosto che aggiungendolo

Dovresti smettere di usare questa metrica, per la maggior parte non ha senso. Coesione, accoppiamento e complessità sono metriche più importanti delle righe di codice.

Come stanno le altre persone?

Sono l'unico sviluppatore a tempo pieno della nostra azienda e negli ultimi 7 anni ho scritto 500.000 righe di codice OCaml e F #, il che equivale a circa 200 righe di codice al giorno. Tuttavia, la stragrande maggioranza di quel codice è costituita da esempi tutorial costituiti da centinaia di progetti separati ciascuno lungo alcune centinaia di righe. Inoltre, ci sono molte duplicazioni tra OCaml e F #. Non stiamo mantenendo alcuna base di codice interna superiore a 50kLOC.

Oltre a sviluppare e mantenere il nostro software, negli ultimi 7 anni ho anche consultato molti clienti del settore. Per il primo cliente , ho scritto 2000 righe di OCaml in 3 mesi, ovvero 20 righe di codice al giorno. Per il prossimo client , quattro di noi hanno scritto un compilatore che ha generato milioni di righe di codice C / C ++ / Python / Java / OCaml e la documentazione in 6 mesi, ovvero 2.000 righe di codice al giorno per sviluppatore. Per un altro cliente, ho sostituito 50kLOC di C ++ con 6kLOC di F # in 6 mesi, ovvero -352 righe di codice al giorno. Per l'ennesimo cliente , sto riscrivendo 15kLOC di OCaml in F # che avrà le stesse dimensioni, quindi 0 righe di codice al giorno.

Per il nostro attuale cliente , sostituirò 1.600.000 righe di codice C ++ e Mathematica con ~ 160kLOC di F # in 1 anno (scrivendo un compilatore su misura) che sarà di -6.000 righe di codice al giorno. Questo sarà il mio progetto di maggior successo fino ad oggi e farà risparmiare ai nostri clienti milioni di dollari all'anno in costi continui. Penso che tutti dovrebbero mirare a scrivere -6.000 righe di codice al giorno.

Senza effettivamente controllare la mia copia di "The Mythical Man-Month" (tutti quelli che leggono questo documento dovrebbero averne una copia prontamente disponibile), c'è stato un capitolo in cui Brooks ha esaminato la produttività per righe scritte. Il punto interessante, per lui, non era il numero effettivo di righe scritte al giorno, ma il fatto che sembrava essere più o meno lo stesso in assemblatore e in PL / I (penso che fosse il linguaggio di livello superiore usato).

Brooks non stava per lanciare una sorta di cifra arbitraria di produttività, ma stava lavorando dai dati su progetti reali e, per quanto ne ricordi, avrebbero potuto essere in media 12 righe / giorno.

Ha sottolineato che la produttività potrebbe variare. Disse che i compilatori erano tre volte più difficili dei programmi applicativi e i sistemi operativi tre volte più difficili dei compilatori. (Sembra che gli sia piaciuto usare moltiplicatori di tre per separare le categorie.)

Non so se apprezzava le differenze individuali tra la produttività del programmatore (anche se in un argomento di ordine di grandezza ha postulato un fattore di sette differenze), ma come sappiamo la produttività superiore non è solo una questione di scrittura di più codice, ma anche scrivere il codice giusto per fare il lavoro.

C'è anche la questione dell'ambiente. Brooks ha speculato un po 'su ciò che renderebbe gli sviluppatori più veloci o più lenti. Come molte persone, si è chiesto se le mode attuali (il debug interattivo utilizzando i sistemi di condivisione del tempo) fossero migliori dei vecchi metodi (attenta pianificazione per uno scatto di due ore usando l'intera macchina).

Detto questo, ignorerei qualsiasi numero di produttività reale che egli ritenesse inutile; il valore continuo del libro è nei principi e nelle lezioni più generali che le persone persistono nel non imparare. (Ehi, se tutti li avessero imparati, il libro sarebbe solo di interesse storico, proprio come tutti gli argomenti di Freud secondo cui esiste qualcosa come una mente subconscia.)

È facile ottenere un paio di centinaia di righe di codice al giorno. Ma cerca di ottenere un paio di centinaia di righe di codice di qualità al giorno e non è così facile. Soprattutto con il debug e il passare dei giorni con poche o nessuna nuova riga al giorno e la media scenderà piuttosto rapidamente. Ho passato settimane a eseguire il debug di problemi difficili e la risposta era 1 o 2 righe di codice.

Sarebbe molto meglio rendersi conto che parlare di linee fisiche di codice è piuttosto insignificante. Il numero di righe di codice fisiche (LoC) è così dipendente dallo stile di codifica che può variare di un ordine di grandezza da uno sviluppatore all'altro.

Nel mondo .NET esiste un modo conveniente per contare il LoC. Punto sequenza . Un punto sequenza è un'unità di debug, è la parte di codice evidenziata in rosso scuro quando si inserisce un punto di interruzione. Con il punto di sequenza possiamo parlare di LoC logico e questa metrica può essere confrontata in vari linguaggi .NET. La metrica del codice LoC logico è supportata dalla maggior parte degli strumenti .NET, tra cui la metrica del codice VisualStudio, NDepend o NCover.

Ad esempio, ecco un metodo 8 LoC (i punti di sequenza parentesi iniziale e finale non vengono presi in considerazione):

La produzione di LoC deve essere conteggiata a lungo termine. Alcuni giorni sputerete più di 200 LoC, altri giorni passerete 8 ore a correggere un bug nemmeno aggiungendo un singolo LoC. Alcuni giorni pulirai il codice morto e rimuoverai LoC, alcuni giorni passerai tutto il tuo tempo a refactoring del codice esistente e non aggiungerai alcun nuovo LoC al totale.

Personalmente, conto un singolo LoC nel mio punteggio di produttività solo quando:

1. È coperto da test unitari
2. è associato a una sorta di contratto di codice (se possibile, non tutti i LoC ovviamente possono essere controllati da contratti).

In questa condizione, il mio punteggio personale negli ultimi 5 anni che codifica lo strumento NDepend per sviluppatori .NET è una media di 80 LoC fisici al giorno senza sacrificare in alcun modo la qualità del codice . Il ritmo è sostenuto e non vedo che diminuisca presto. Tutto sommato, NDepend è una base di codice C # che attualmente pesa circa 115 K LoC fisico

Per coloro che odiano contare LoC (ne ho visti molti nei commenti qui), attesto che una volta calibrato adeguatamente, contare LoC è un eccellente strumento di stima . Dopo aver codificato e misurato decine di funzionalità ottenute nel mio particolare contesto di sviluppo, sono arrivato al punto in cui posso stimare con precisione le dimensioni di qualsiasi funzionalità TODO in LoC e il tempo che impiegherò per consegnarlo alla produzione.

Non esiste un proiettile d'argento.

Una sola metrica del genere è inutile da sola.

Ad esempio, ho la mia libreria di classi. Attualmente sono vere le seguenti statistiche:

Linee totali: 252.682
Linee di codice: 127.323
Commenti: 99.538
Linee vuote: 25.821

Supponiamo che non scriva alcun commento, ovvero 127.323 righe di codice. Con il tuo rapporto, quella libreria di codici mi richiederebbe 10610 giorni per scrivere. Sono 29 anni.

Certamente non ho passato 29 anni a scrivere quel codice, dato che è tutto C # e C # non esiste da così tanto tempo.

Ora, puoi sostenere che il codice non è poi così buono, dal momento che ovviamente devo aver superato la metrica delle 12 righe al giorno, e sì, accetto questo, ma se devo ridurre la sequenza temporale a quando è stato rilasciato 1.0 (e non ho iniziato a realizzarlo fino al rilascio di 2.0), ovvero 2002-02-13, circa 2600 giorni, la media è di 48 righe di codice al giorno.

Tutte quelle righe di codice sono buone? Diamine no. Ma fino a 12 righe di codice al giorno?

Diamine no.

Tutto dipende.

Puoi avere un programmatore di alto livello che produce codice nell'ordine di migliaia di righe al giorno e un programmatore medio che produce codice nell'ordine di centinaia di righe al giorno e la qualità è la stessa.

E sì, ci saranno bug.

Il totale che desideri è il saldo. La quantità di codice è cambiata, rispetto al numero di bug trovati, rispetto alla complessità del codice, rispetto alla difficoltà di correggere quei bug.

Steve McConnell fornisce una statistica interessante nel suo libro "Software Estimation" (p62 Tabella 5.2). Distingue tra tipi di progetto (Avionic, Business, Telco, ecc.) E dimensioni del progetto 10 kLOC, 100 kLOC, 250 kLOC. I numeri sono indicati per ogni combinazione in LOC / StaffMonth. EG Avionic: 200, 50, 40 Sistemi Intranet (interni): 4000, 800, 600 Sistemi integrati: 300, 70, 60

Il che significa: ad es. per il progetto Avionic 250-kLOC ci sono 40 (LOC / mese) / 22 (giorni / mese) == <2LOC / giorno!

Penso che questo provenga dai giorni di sviluppo della cascata , in cui la fase di sviluppo reale di un progetto potrebbe essere solo il 20-30% del tempo totale del progetto. Prendi le linee totali di codice e dividi per l'intero tempo del progetto e otterrai circa 10 linee / giorno. Dividi solo per il periodo di programmazione e ti avvicinerai a ciò che la gente sta citando.

La nostra base di codice è di circa 2,2 MLoC per circa 150 anni di lavoro. Ciò rende circa 75 linee di c ++ o c # per sviluppatore al giorno, per tutta la vita del progetto.

Penso che le dimensioni del progetto e il numero di sviluppatori coinvolti siano fattori importanti in questo. Sono molto al di sopra della mia carriera, ma ho lavorato da solo tutto il tempo, quindi non c'è alcuna perdita nel lavorare con altri programmatori.

Buona pianificazione, buon design e buoni programmatori. Ottieni tutto ciò insieme e non passerai 30 minuti a scrivere una riga. Sì, tutti i progetti richiedono di interrompere e pianificare, riflettere, discutere, testare ed eseguire il debug ma a due righe al giorno ogni compagnia avrebbe bisogno di un esercito per far funzionare tetris ...

In conclusione, se lavorassi per me a 2 righe all'ora, è meglio che mi prendi un sacco di coffes e mi massaggi i piedi in modo da non farti licenziare.

Si sospetta che questo perenne frammento di manager-candy sia stato coniato quando tutto era un'app di sistema scritta in C perché se non altro il numero magico sarebbe variato di ordini di grandezza a seconda della lingua, della scala e della natura dell'applicazione. E poi devi scontare commenti e attributi. E alla fine a chi importa del numero di righe di codice scritte? Dovresti aver finito quando hai raggiunto le linee 10K? 100K? Così arbitrario.

È inutile.