it-swarm.it

Quante righe di codice può produrre uno sviluppatore C # al mese?

Un dirigente del mio posto di lavoro ha posto a me e al mio gruppo di sviluppatori la domanda:

Quante righe di codice può produrre uno sviluppatore C # al mese?

Un vecchio sistema doveva essere portato su C # e vorrebbe che questa misura fosse parte della pianificazione del progetto.

Da una fonte (apparentemente credibile) aveva la risposta di "10 SLOC/mese" ma non ne era contento.

Il gruppo ha convenuto che questo era quasi impossibile da specificare perché dipendeva da un lungo elenco di circostanze. Ma potremmo dire che l'uomo non se ne andrebbe (o rimarrebbe molto deluso da noi) se non ci arrivasse una risposta che gli si adatti meglio. Quindi è partito con la risposta molte volte migliore di "10 SLOC/giorno"

È possibile rispondere a questa domanda? (a mano o anche con qualche analisi)

21
lox

Chiedi al tuo dirigente quante pagine di contratto può scrivere il suo avvocato al mese. Quindi (si spera) si renderà conto che c'è un'enorme differenza tra la scrittura di un contratto di una sola pagina e la scrittura di un contratto di 300 pagine senza scappatoie e contraddizioni. O tra la scrittura di un nuovo contratto e la modifica di uno esistente. O tra scrivere un nuovo contratto e tradurlo in un'altra lingua. O a un diverso sistema giuridico. Forse sarà anche d'accordo sul fatto che le "pagine di contratto per unità di tempo" non sono una misura molto buona per la produttività dell'avvocato.

Ma per darti alcuni risposta alla tua vera domanda: nella mia esperienza, per un nuovo progetto alcune centinaia di SLOC al giorno e lo sviluppatore non sono rari. Ma non appena compaiono i primi bug, questo numero scenderà bruscamente.

84
nikie

Quante righe di codice può produrre uno sviluppatore C # al mese?

Se sono buoni, meno di zero.

33
quentin-starin

Corri dall'altra parte ... Adesso.

LoC è una delle peggiori metriche che puoi usare.

I cattivi sviluppatori possono potenzialmente scrivere più LoC al giorno rispetto ai buoni sviluppatori, ma sfornano il codice della spazzatura.

A seconda della complessità del codice, il porting può essere eseguito da processi di automazione che porterebbero a grandi migliaia di modifiche + LoC al giorno, mentre sezioni più difficili in cui i costrutti del linguaggio sono selvaggiamente codice diverso vengono portate a 100LoC al giorno.

Mandalo a leggere la pagina di Wikipedia su SLOC . Se fornisce alcuni esempi piacevoli e semplici del perché è una metrica così scarsa.

21
Dan McGrath

La risposta giusta: No ...

Questo dirigente dovrebbe essere istruito, che SLOC non è una metrica valida per i progressi dell'analisi

La risposta sciatta: qualsiasi numero che puoi inventare.

Basta dargli un numero, tu e la tua squadra potete facilmente fare quel numero comunque. (Mettendo a meno linee, righe vuote, commenti ecc. Ecc., Solo per consentire a questo ragazzo di continuare a vivere nel suo mondo fantastico, e perseguitare ancora un'altra squadra e continuare il ciclo rinforzato dalla miseria che fa una storia per il futuro.

Non bello, ma fattibile.

18
Zekta Chan

Dal primo sguardo questa domanda sembra assolutamente stupida, e tutti qui hanno risposto solo alla stupida C # LoC. Ma c'è una sfumatura importante: si tratta di una prestazione porting. Il modo giusto di porre questa domanda è chiedere, quante righe di codice del progetto sorgente (quello che viene portato) può essere gestita da uno sviluppatore in una determinata unità di tempo. È una domanda perfettamente giustificata, poiché è noto il numero totale di righe di codice ed è esattamente la quantità di lavoro da svolgere. E il modo giusto per rispondere a questa domanda è quello di raccogliere un po 'di dati storici: lavorare per, diciamo, una settimana e misurare le prestazioni di ciascuno degli sviluppatori.

10
SK-logic

Ho solo una cosa da dire:

"Misurare l'avanzamento della programmazione mediante righe di codice è come misurare il progresso della costruzione di aeromobili in base al peso."

- Bill Gates

Successivamente, potresti obiettare che Bill Gates non sapeva come realizzare software di successo;)

Nota: SLOC è comunque un'ottima misura della complessità della base di codice!

7
Matthieu M.
I 
can
write
large
numbers
of
lines
of
code
per
month.

In proporzione al numero di parole, in effetti.

Vedi il mio punto?

5
JBRWilkinson

In genere è una cattiva idea chiamare il tuo capo un idiota, quindi i miei suggerimenti iniziano con la comprensione e la discussione delle metriche, piuttosto che respingerle.

Alcune persone che in realtà non sono considerate idioti hanno utilizzato metriche basate su righe di codice. Fred Brooks, Barry Boehm, Capers Jones, Watts Humphries, Michael Fagan e Steve McConnell li hanno usati tutti. Probabilmente li hai usati anche se solo per dire a un collega, questo modulo di Dio ha 4000 linee, deve essere suddiviso in classi più piccole.

Esistono dati specifici relativi a questa domanda da una fonte che molti di noi rispettano.

http://www.codinghorror.com/blog/2006/07/diseconomies-of-scale-and-lines-of-code.html

http://www.codinghorror.com/blog/2005/08/are-all-programming-languages-the-same.html

http://discuss.joelonsoftware.com/default.asp?joel.3.286106.22

Ho il sospetto che il miglior uso della riga di codice all'ora del programmatore sia quello di dimostrare che per tutta la durata del progetto, questo valore inizierà piuttosto elevato, ma man mano che i difetti vengono rilevati e corretti, verranno aggiunte nuove righe di codice per risolvere problemi che non facevano parte delle stime originali e le righe di codice rimosse per eliminare la duplicazione e migliorare l'efficienza mostreranno che LOC/h indica cose diverse dalla produttività.

  • Quando il codice viene scritto velocemente, sciatto, gonfio e senza alcun tentativo di refactoring, l'efficienza apparente sarà al massimo. La morale qui sarà che devi stare attento a ciò che misuri.
  • Per uno sviluppatore particolare, se questa settimana aggiunge o tocca una quantità elevata di codice, la settimana successiva potrebbe esserci un debito tecnico da pagare in termini di revisione, test, debug e rilavorazione del codice.
  • Alcuni sviluppatori lavoreranno a un tasso di output più costante rispetto ad altri. Si può scoprire che trascorrono la maggior parte del tempo a ottenere buone storie utente, si girano molto rapidamente e fanno test unitari corrispondenti, quindi si girano e fanno rapidamente codice incentrato solo sulle storie utente. Il take away qui è che gli sviluppatori metodici avranno probabilmente una rapida svolta, scriveranno codice compatto e avranno una bassa rielaborazione perché comprendono molto bene il problema e la soluzione prima di iniziare a scrivere codice. Sembra ragionevole che codificheranno meno perché codificano solo dopo averlo riflettuto, anziché prima e dopo.
  • Quando il codice viene valutato per la sua densità di difetto, si scoprirà che non è uniforme. Alcuni codici spiegheranno la maggior parte dei problemi e dei difetti. Sarà un candidato per la riscrittura. Quando ciò accadrà, diventerà il codice più costoso perché in virtù del suo elevato grado di rilavorazione. Avrà le righe lorde più alte di conteggi di codice (aggiunte, cancellate, modificate, come potrebbe essere riportato da uno strumento come CVS o SVN), ma le righe nette più basse di codice all'ora investite. Questo può finire per essere una combinazione del codice o implementando il problema più complesso o la soluzione più complicata.

Indipendentemente da come si sviluppa il dibattito sulla produttività del programmatore in righe di codice, scoprirai che hai bisogno di più risorse umane di quelle che puoi permetterti e il sistema non sarà mai completato in tempo. I tuoi veri strumenti non sono metriche. Usano una metodologia superiore, i migliori sviluppatori che puoi assumere o addestrare e il controllo di portata e rischio (probabilmente con metodi Agile).

4
DeveloperDon

Potrei avere una posizione leggermente diversa su questo, ma penso che potrei capire perché l'esecutivo stava cercando queste informazioni se stanno attualmente pianificando il progetto. Poiché è difficile stimare quanto tempo impiegherà un progetto, uno dei metodi utilizzati (vedi: Stima del software: demistificazione dell'arte nera ) è stimare quanto tempo impiegherà il progetto sulla base del numero di SLOC in progetti simili e ora gli sviluppatori possono produrre in media. In pratica, ciò dovrebbe essere fatto utilizzando record storici che il gruppo ha a disposizione per progetti simili con sviluppatori uguali o simili.

Tuttavia, non vale nulla che queste stime siano intese solo per la pianificazione di base del progetto e non siano in realtà destinate a stabilire il ritmo degli sviluppatori nel progetto perché le cose cambiano di giorno in giorno. Pertanto, la maggior parte di ciò che leggi sull'uso degli SLOC come strumento di stima è che sono buoni a lungo termine se hai già un buon corpus di conoscenze, ma sono pessimi per l'uso quotidiano.

4
rjzii

Posso dirti che un sacco di appaltatori per un grande progetto ha scritto 15000 LOC (ciascuno) in un anno. Questa è una risposta incredibilmente approssimativa, ma ci è stata utile poiché abbiamo 400.000 LoC C++ esistenti e siamo riusciti a capire che la conversione di tutto in C # ci richiederebbe circa 26 anni-uomo per il completamento. Prendere o lasciare.

Quindi ora sappiamo il grosso ordine di grandezza, possiamo pianificare meglio per questo - ottenere 20 sviluppatori e stimare il lavoro di un anno per loro sarebbe tutto a posto. Prima di contare, non avevamo idea di quanto tempo ci sarebbe voluto per migrare.

Quindi il mio consiglio per te è di controllare tutto il codice che hai scritto in un determinato periodo di tempo (sono stato fortunato ad avere un nuovo progetto con cui lavorare), quindi eseguire uno dei tanti strumenti di metrica del codice su di esso. Dividi il numero per ora e puoi dargli una risposta precisa - quanto LOC in realtà scrivi al giorno. Per noi, è uscito a 90 LOC al giorno! Immagino che abbiamo avuto molte riunioni e documentazione su quel progetto, ma credo che avremo molte riunioni e documentazione anche sul prossimo :)

3
gbjbaanb

Dagli una metrica migliore con cui lavorare

Invece di LOC , spiega che è la metrica peggiore da usare. Quindi dagli un'alternativa:

Numero di funzioni/caratteristiche Per Caratteristica/Richieste di funzioni -> NOFF/RFF

Potrebbe essere necessario aggiungere una ponderazione/normalizzazione oltre a NOFF/RFF, per soddisfare gli importi delle richieste settimanali.

:) chiaramente quanto sopra è inventato, ma qualsiasi cosa, è meglio di SLOC ...

3
Darknight

Sembra corretto.

https://stackoverflow.com/questions/966800/mythical-man-month-10-lines-per-developer-day-how-close-on-large-projects

Se si tiene conto del debug, della documentazione, della pianificazione, ecc. La media è di circa 10 righe di codice al giorno. In realtà classificherei 10 righe al giorno nella parte alta (cioè uno sviluppatore molto produttivo).

Anche se puoi sfornare un paio di centinaia di righe in un solo giorno (questo non è sostenibile). Non si tratta di un codice di qualità fino a quando non hai aggiunto tutti i test unitari alla documentazione e, naturalmente, il debug del codice dopo che il test unitario mostra gli errori. Dopo tutto ciò che hai fatto sei tornato a 10.

2
Martin York

Altre risposte sono corrette, è una domanda stupida e la risposta non significa una dannata cosa. È tutto vero, ma mi capita di sapere quante righe di codice ho prodotto in circa un mese.

Sono circa 3000 righe di codice C # senza XML-doc. Stavo implementando nuove funzionalità e ho finito con questo importo in un mese o un mese e una settimana. È tutto ciò che è finito nel controllo del codice sorgente, molto codice è stato scritto e quindi refactored o eliminato.

Sono uno sviluppatore C # e sto cercando di essere bravo a farlo, ma non posso dirti quanto oggettivamente sono bravo. Ho provato a scrivere un buon codice e ho fatto molti sforzi per renderlo facile da mantenere. Ho inserito commenti solo una o due volte in questo codice.

Non so se siano troppe o troppo poche righe di codice e devo dire che non mi interessa davvero. È un dato privo di significato e non può essere utilizzato in modo sicuro per l'estrapolazione in alcun modo. Ma mi capita di conoscere questi dati, quindi ho deciso di condividere.

1
Dyppl

Lascia che il tuo manager lo gestisca o inizia la ricerca di lavoro.

In tutta serietà, potresti spenderlo in quello che potrebbe essere uno sforzo senza speranza nel spiegare all'esecutivo i metodi corretti e impropri per misurare i progressi di un progetto verso il completamento. In ogni realtà, tuttavia, a cosa servono i responsabili di ingegneria e di progetto.

D'altra parte, le circostanze sono tali che il dirigente in questione È il tuo ingegnere e/o project manager. Hai problemi molto più grandi e di base, anche se non si sono ancora rivelati. In questo caso un problema come questo può fungere da "avvertimento" per i maggiori problemi a venire.

1
mummey

Suppongo che uno sviluppatore che lavora con un linguaggio come C # dovrebbe essere in grado di scrivere/generare circa 10K LoC/giorno. Suppongo che potrei farlo. Non lo farei mai.

Quello che vuoi da uno sviluppatore è fare il suo lavoro in 10 LoC/giorno. Meno codice è sempre meglio. Spesso inizio a produrre una grande quantità di codice e poi a tagliare via fino a raggiungere il massimo della semplicità, quindi in realtà ho giorni con LoC negativi.

In un certo senso, la programmazione è come la poesia. La domanda non è: quante righe un poeta può scrivere, ma quanto può trasmettere nelle 14 righe di un sonetto.

1
back2dos

Bene, sono un po 'in ritardo a questa festa come al solito, ma in realtà è interessante. Inizialmente avevo lo stesso pensiero della maggior parte del fatto che la domanda del dirigente fosse stupida. Tuttavia, ho letto la risposta di SK-logic e ho capito che si tratta di una domanda sensata posta in modo insensato. Oppure, in altre parole, c'è un problema valido dietro la domanda.

I manager devono spesso provare a determinare la fattibilità, i finanziamenti, il personale, ecc. Per un progetto. Questo è un problema ragionevole. Per un porto di straightford, una stima basata su linee di codice di porta divise per la media delle linee di codice stimate per sviluppatore al giorno è attraente in semplicità, ma destinata a fallire per tutti i motivi indicati in questa pagina.

Un approccio più sensato sarebbe: -

  1. Per una stima in loco, chiedi agli sviluppatori con più esperienza con il codice una stima visiva di quanto tempo ci vorrà. Questo è destinato ad essere errato per molte ragioni che non entrerò qui, ma è il migliore che potranno fare all'inizio. Almeno dovrebbero avere un'idea se sarà facile farlo tra una settimana o anni, anche con risorse aggiuntive. Se sono state eseguite porte o lavori di dimensioni simili, potrebbero utilizzarle come guida.
  2. Stimare la porta per componente per ottenere un dimensionamento totale. È necessario includere attività che non sono direttamente correlate alla porta, come la creazione di infrastrutture (macchine, sistemi di costruzione, ecc.), Lo studio e l'acquisto di software, ecc.
  3. Identifica i componenti più rischiosi della porta e inizia prima con quelli. È probabile che questi espellano maggiormente la stima, quindi dovrebbero essere eseguiti anticipatamente, se possibile, in modo tale che nel porto ci siano limitate sorprese.
  4. Tieni traccia dei progressi rispetto al dimensionamento fatto nel passaggio 2 per calcolare continuamente la durata prevista del porto. Man mano che il progetto avanza, questo dovrebbe diventare più preciso. Ovviamente, il numero di righe di codice trasferite (funzionalità nella base di codice originale che ora si trovano nel codice trasferito) può essere utilizzato anche come metrica ed è effettivamente utile per garantire che il prodotto originale venga portato anziché un sacco di nuove fantastiche funzionalità aggiunte mentre non si affronta la porta effettiva.

Si tratterebbe di semplici passi, ovviamente ci sono molte altre attività intorno a ciò che sono utili come investigare strumenti di porting e framework collegabili, creare prototipi, determinare ciò che realmente deve essere portato, riutilizzare strumenti e infrastrutture di test, ecc.

0
acarlon