Esistono noti usi validi di SLOC per misurare la produttività?

Ho avuto una conversazione insolita e breve con un architetto molto anziano su linguaggi dinamici e statici. Ha detto che i dati dell'azienda mostrano che ci sono prove per una maggiore produttività quando vengono utilizzati linguaggi statici. Nota, è una grande azienda con una lunga storia. Con mia (e altre) sorpresa, la metrica che ha usato sono state le righe di codice aggiunte.

Ha rapidamente respinto le obiezioni relative alla metrica affermando che all'interno di una stessa azienda, con cultura, linea di business e dati simili, le differenze (rispetto a situazioni e capacità uniche degli individui) si fondono abbastanza in modo che la metrica SLOC sia utile per confrontare la produttività di strumenti e lingue.

Anche se non credo che questa affermazione sia supportata da una rigorosa analisi statistica, ci sono alcune prove nel settore che potrebbero supportare questa linea di pensiero?

L'argomento dell'architetto senior potrebbe significare due cose.

1. Può significare che uno sviluppatore medio dell'azienda produce più righe di codice quando utilizza linguaggi statici rispetto a quelli dinamici. Ad esempio, se quindici sviluppatori lavorano con Java per sei mesi, scriveranno 100 KLOC e se gli stessi quindici sviluppatori lavorano con Python per sei mesi, scriveranno solo 50 KLOC.

   Non vi è alcuna correlazione tra LOC e produttività qui. Cosa succede se ci vogliono quattro volte più righe di codice in Java per produrre la stessa funzionalità rispetto a Python? Se ciò è vero, l'uso di Python comporterebbe un doppio della produttività, in base alle metriche KLOC sopra.

2. Può anche significare che uno sviluppatore medio nell'azienda produce meno righe di codice quando usa linguaggi statici rispetto a quando ne usano uno dinamico: quindici sviluppatori scriveranno in sei mesi 100 KLOC in Java o 200 KLOC in Python.

   Mentre di solito è meglio meno righe di codice (meno codice da scrivere, leggere e mantenere), non è ancora chiaro quante funzioni abbiano prodotto gli sviluppatori Java rispetto a quelle di Python. Forse hanno scritto mezze righe di codice rispetto agli sviluppatori Python, ma hanno anche prodotto la metà del numero di funzionalità?

In entrambi i casi, LOC non è una metrica preziosa, poiché la stessa funzionalità non si tradurrebbe nella stessa quantità di righe di codice in lingue diverse . Alcune lingue tendono ad essere più dettagliate; altri: più compatti. Mentre in alcuni casi la compattezza è preziosa, non esiste una regola generale per questo. Un esempio estremo sarebbe il linguaggio Brainfuck che ha un'estrema compattezza, ma che non è popolare per la sua leggibilità. Confrontare anche lingue simili potrebbe essere complicato: ad esempio, quando si tratta di parentesi graffe, Java segue lo stile K&R, mentre in C #, la parentesi graffa di apertura è sulla propria linea nella maggior parte dei casi quando si segue lo stile ufficiale, che porta a un artificiale aumento dei LOC per C #. E cosa succede quando si confronta un linguaggio procedurale con un linguaggio orientato agli oggetti o con un linguaggio funzionale?

Invece di utilizzare una metrica soggetta a errori, l'architetto senior potrebbe fare affidamento su un gruppo di metriche che misurano la produttività se utilizzate insieme: il numero di funzionalità sviluppate al mese, il numero di bug introdotti nella base di codice e il tempo impiegato per risolverli , l'evoluzione del debito tecnico, ecc. Questo confronto potrebbe essere complicato all'inizio, dal momento che si deve tener conto della non familiarità della squadra con la nuova lingua. Una volta che il team ne avrà abbastanza familiarità, la scelta dovrebbe basarsi su metriche stabili, nonché nella maggior parte delle preferenze dei membri del team stesso.

LOC ha un valore in alcune situazioni ristrette. Ad esempio, potrebbe fornire un suggerimento sulla dimensione del progetto e su parti del progetto (e in media si correla con i punti funzione, pur essendo spesso più facile da misurare), oppure potrebbe indicare i metodi e le classi che potrebbero richiedere ulteriore attenzione perché delle loro grandi dimensioni. Tuttavia, LOC dovrebbe essere usato con cura, poiché è usato troppo spesso da persone che immaginano una correlazione tra cose non correlate. L'uso più umanamente disastroso dei LOC è stato in passato il tentativo di misurare la produttività di un singolo sviluppatore in base ai LOC scritti al mese.

A proposito di produttività e SLOC

Il problema con SLOC

Il problema con la metrica SLOC è che misura un'approssimazione della quantità di codice scritto, senza tener conto di:

• la qualità del codice (ovvero se per ogni 100 SLOC dovessi aggiungere altri 90 SLOC a causa di bug, ma che non conosci al momento della consegna del tuo codice?)
• gli obiettivi raggiunti con il codice (ovvero lo SLOC 10K gestisce tutti i casi d'uso previsti o le storie degli utenti? o solo un piccolo sottoinsieme?)
• la manutenibilità del codice (ovvero dovrete aggiungere l'1% o il 50% in più di codice per adeguare il codice a prevedibili requisiti in evoluzione?).

In caso contrario, la produzione di un codice spaghetti non mantenibile soggetto a errori con molte parti incollate sarà considerata più produttiva del codice riutilizzabile attentamente progettato.

Quindi SLOC non è sicuramente il modo migliore per misurare la produttività.

Quale produttività stiamo considerando?

La produttività è misurata per un processo. Quindi SLOC potrebbe essere un indicatore perfettamente valido per il solo processo di codifica.

Se, ad esempio, fraintendete i requisiti scadenti, spendete cinque mesi per produrre il software, mostratelo all'utente, scoprite che è assolutamente sbagliato e impiegate altri 5 mesi per riscriverlo da zero, avreste la stessa produttività in SLOC / mese, che una squadra che scrive il codice alla prima volta, ad esempio perché ha utilizzato un processo agile che riduce i malintesi attraverso frequenti feed-back. Questa apparente uguale produttività nasconde enormi problemi.

Pertanto, la misurazione della produttività dello sviluppo software deve tenere conto dell'intero processo, compresa l'analisi dei requisiti, la progettazione di cosa codificare, la codifica, i test, il debug e la verifica del rispetto delle aspettative degli utenti. Poiché tutte queste attività sono molto diverse, la cosa migliore è misurare l'unica cosa che conta: software funzionante, ovvero cosa significa il software prodotto per l'utente .

Come misurare i prodotti software?

Esistono diversi approcci:

• L'approccio tipico nell'ingegneria del software classico è Function Points (FP). I punti funzione vengono misurati in base ai requisiti da soddisfare (ad es. Numero di moduli, numero di campi in ciascun modulo, ecc ...). La produttività viene quindi misurata in FP per unità di tempo e per persona. Alcune aziende hanno persino dati che indicano quanti punti funzione uno sviluppatore può produrre per unità di tempo in una determinata lingua per un determinato dominio. Il problema con FP è che richiede requisiti molto dettagliati e richiede tempo.
• Un approccio più moderno e pragmatico è lo story points (SP). Questi vengono utilizzati per valutare la complessità del codice da produrre e vengono abitualmente utilizzati per valutare la velocità dei team di sviluppo. Tuttavia, SP è una misura di stima per il lavoro svolto prima che tutti i dettagli siano noti. Non è una misura finale di ciò che è realmente accaduto. Pertanto, è necessario prestare attenzione quando lo si utilizza come misura di produttività perché potrebbe ritorcersi contro il processo di stima .

Informazioni sulla produttività della digitazione statica o dinamica

Devo confessare che sono personalmente un fan dei linguaggi tipicamente statici, perché nel mio io interiore so che è più affidabile (anni di programmazione mi hanno dimostrato che).

Quindi una cosa che prendo per certo è che il linguaggio tipizzato staticamente è in grado di prevenire molti più errori / bug in fase di compilazione (ad esempio errori di battitura, mancata corrispondenza nei tipi previsti, ecc ...) rispetto ai linguaggi non tipizzati staticamente. Ma in tutta l'obiettività, non oserei generalizzare abusivamente questo come una maggiore produttività.

Il tuo architetto ha ragione?

Forse sì forse no.

Ma i suoi argomenti non sembrano validi: l'aumento di produttività del linguaggio tipizzato staticamente deriva da un numero significativo di errori che vengono colti in anticipo dal compilatore.

Di conseguenza, non è possibile scoprire questo "maggiore" aumento di produttività osservando SLOC da solo senza esaminare la rilavorazione richiesta per i linguaggi tipizzati dinamicamente. Quindi il suo confronto non può essere giusto.

Nemmeno l'argomento di circostanze comparabili. Alcune lingue tipizzate dinamicamente consentono alcuni costrutti di livello superiore che richiedono meno codice rispetto a fare lo stesso in una delle classiche lingue tipizzate staticamente. Quindi potresti aver bisogno di meno tempo, scrivere meno codice, ma aggiungere lo stesso overhead di analisi, test e verifica. Quindi misurare la produttività da parte della SLOC diluirebbe i potenziali guadagni di produttività, creando così un pregiudizio contro il linguaggio tipizzato in modo dinamico.

Qualche studio a supporto di tale affermazione?

Esistono numerosi studi accademici recenti sull'argomento. Sebbene alcuni di essi vedano un vantaggio della digitazione statica, è generalmente limitato a uno scopo specifico (documentazione, riutilizzo di codice o API scarsamente documentati, ecc.). La formulazione prudente viene anche utilizzata perché i moderni IDE hanno ridotto significativamente i rischi legati alla tipizzazione dinamica:

• Un confronto empirico di sistemi di tipo statico e dinamico sull'uso delle API in presenza di un IDE: Java vs. groovy con eclipse , 2014
• Considerando gli effetti sulla produttività delle dichiarazioni esplicite sul tipo , 2014, ma non conclusivi
• Uno studio empirico sull'influenza dei sistemi di tipo statico sull'usabilità di software non documentato

Ecco un controesempio per il tuo architetto senior: Supponiamo che io voglia scrivere una gerarchia di tre classi, due delle quali derivano dalla terza, implementando alcune funzioni virtuali definite dalla classe base.

Se scrivo queste tre classi in C ++, è piuttosto semplice. Dichiaro le lezioni, uso virtuale nei posti corretti e finisco.

Se scrivo queste tre classi in C, dovrò aggiungere un po 'di codice: ho bisogno di definire structs per le v-table, ho bisogno di aggiungere un puntatore v-table alla classe base, devo aggiungere codice ai costruttori per impostare effettivamente i puntatori v-table, ho bisogno di aggiungere codice ai costruttori per chiamare effettivamente il costruttore della classe base, ho bisogno di aggiungere il codice per eseguire l'allocazione della memoria esplicitamente prima di chiamare un costruttore (cosa che C ++ newfa in un solo passaggio ), allo stesso modo, devo separare la distruzione dalla free()chiamata successiva , e così via, e così via.

Il punto è che tutte queste cose aggiuntive sono piuttosto insensate. Posso farli molto rapidamente. Quindi, non ci vorrà molto più tempo per scrivere la versione C di quanto sia necessario per scrivere la versione C ++. Tuttavia, ho prodotto molte più righe di codice C rispetto al codice C ++. Tanto che sembrerò essere stato più produttivo in C in termini di SLOC.

Qualsiasi lingua che richieda una certa quantità di codice del bollettino apparirà più produttiva in termini di SLOC di una lingua che non richiede la stessa quantità di codice del bollettino.

Vedete, l'argomento SLOC è così fondamentalmente imperfetto, che in realtà lo vedrei al contrario: prenderei l'affermazione "i programmatori tendono a produrre più SLOC in linguaggi statici" per dire: "i linguaggi statici sembrano richiedere di più codice del boilerplate e quindi ridurre la produttività ".

Sarò il contrarian.

Tracciamo SLoC nel nostro lavoro (anche se non lo usiamo direttamente nelle decisioni del personale) e ho avuto persone che discutono di ciò che la maggior parte delle persone dice nelle loro risposte. In effetti, "LoC non ha importanza perché la tecnologia X ci consente di fare di più con meno codice" o "Gli sviluppatori migliori scrivono meglio, codice più breve e quindi non scrivono più di chiunque altro". Nella mia esperienza (anche se non ho numeri concreti per sostenere queste cose), queste obiezioni semplicemente non sono corrette. Ai miei tempi ho visto una chiara correlazione sia nella velocità che nella qualità della produzione di codice per i nostri sviluppatori, se confrontata con tutte le altre misurazioni significative della loro "competenza" complessiva come ingegnere. Per fornire alcuni contro-esempi al tipo di argomenti fatti sopra:

1. Sì, alcune lingue possono fare di più con meno codice. In effetti, abbiamo creato un intero framework che "automatizza" gran parte dello sviluppo per i nostri particolari problemi aziendali (solo back-end). Il risultato di tutto ciò non è che le persone scrivono meno codice, ma semplicemente che abbiamo più tempo per scrivere codice. Di conseguenza, nella nostra azienda, il tasso complessivo di scrittura del codice è abbastanza costante tra le tecnologie e dipende principalmente dal livello di competenza dell'ingegnere.
2. L'idea che uno sviluppatore migliore produrrà meno codice perché sta scrivendo in modo più intelligente non è assolutamente vera. Sì, un programma meglio progettato potrebbe occupare meno righe di codice. Tuttavia, ho scoperto personalmente che gli sviluppatori "migliori" che scrivono codice più efficiente non impiegano più tempo a pianificarlo di quanto uno sviluppatore più giovane scriva cose a lungo. Di conseguenza, lo sviluppatore più senior eseguirà le attività di codifica più rapidamente e passerà a scrivere codice diverso allo stesso ritmo elevato.

Quella parte lat è il mio riassunto generale, BTW. Quello che ho scoperto è che, indipendentemente dallo stack tecnologico o dal tipo di progetto, la maggior parte degli sviluppatori ha il proprio ritmo, che è il ritmo a cui operano. Se una lingua ha molte funzionalità che rendono più efficace il codice degli sviluppatori, questo è un grande vantaggio per l'azienda, ma ciò non significa che scriveranno meno codice di conseguenza. Al contrario, ottengono le funzionalità più rapidamente e passano rapidamente al nuovo codice. Ancora una volta, il risultato finale è che valutano il modo in cui codificano dipende principalmente dalla loro abilità e meno dal loro stack tecnologico. In effetti, per questo motivo, mi aspetto generalmente che lo stack tecnologico faccia più differenza sulla velocità con cui i biglietti e le funzionalità vengono sviluppati rispetto alla velocità con cui le persone codificano.

Detto questo, né il tasso di scrittura del codice né il tasso di chiusura dei biglietti sono una misura perfetta della produttività, motivo per cui non prendiamo direttamente decisioni sul personale sulla base di SLoC. Invece fa parte del processo e le valutazioni dei dipendenti vengono eseguite utilizzando il maggior numero possibile di punti dati. Direi però che il tuo architetto non è certamente pazzo.

Un'eccezione

L'unica eccezione con cui sono d'accordo è la possibilità del codice targa caldaia. Se c'è un sacco di copia e incolla in corso da una classe (o qualsiasi altra) a un'altra per metterlo in funzione, allora questo ovviamente distorcerà le metriche. Ciò vale anche se si dispone di strumenti in grado di generare automaticamente grandi quantità di codice. Tuttavia, penso che queste saranno spesso l'eccezione piuttosto che la regola. Se i tuoi sviluppatori impiegano un po 'di tempo a copiare il codice della piastra della caldaia per iniziare, stai utilizzando il set tecnologico errato. Se in realtà stanno scrivendo il codice, anche se è abbastanza ripetitivo, allora mi aspetto che questo distorca qualsiasi misura solo una piccola quantità: quando scriviamo il codice, il più delle volte siamo limitati da quanto velocemente possiamo pensare attraverso il problema piuttosto di quanto velocemente possiamo digitare. Anche quando si scrive codice relativamente ripetitivo,

Ovviamente, tutto quanto sopra si basa sulla mia esperienza personale. Il tuo chilometraggio può variare e ovviamente sono in minoranza. Sentiti libero di non essere d'accordo. In sintesi però:

Trovo che il tasso di codifica dipenda più da quanto velocemente puoi pensare attraverso i tuoi problemi che da qualsiasi altra cosa. Di conseguenza, ho scoperto che la velocità di codifica è una misura decente della produttività, anche tra i set tecnologici, con solo alcune possibili eccezioni.

Anche se sto saltando sul carrozzone. Penso che l'impatto sul comportamento dei programmatori debba essere evidenziato.

L'uso di SLOC come misura di produttività ha un effetto tossico sul morale del programmatore. Nel momento in cui un ingegnere del tuo team / azienda si rende conto che sono misurati su SLOC accadono diverse cose:

1. Iniziano a scrivere codice molto più lungo per fare la stessa funzione
2. si preoccuperanno meno della qualità del loro codice
3. smetteranno di fare altre cose che aiutano la tua squadra (reclutamento, debug, aiuto ai giovani)
4. odieranno il loro lavoro e probabilmente se ne andranno

Non posso sottolineare abbastanza quanto sia corrosivo ingegnerizzare il morale poiché l'ho visto accadere due volte in 2 diverse aziende. Qualunque sia il caso d'uso apparentemente valido che hai per esso, sostengo che è improbabile che valga la pena l'impatto sul tuo team / azienda anche se c'è solo una piccola possibilità che il suo utilizzo venga scoperto. Anche se in alcuni casi esiste forse una correlazione tra il numero di righe scritte e la quantità di funzioni utili, incoraggia tutti i comportamenti sbagliati nei programmatori e invia il messaggio la qualità non è importante.

Non è generalmente considerato un modo valido per misurare la produttività. Un codice più piccolo di solito è meglio di un codice più grande, quindi uno sviluppatore più produttivo di solito produce meno codice. La produttività ha il suo maggior successo nel debug; gli sviluppatori efficienti impiegano poco tempo per il debug.

I linguaggi tipizzati staticamente sono più produttivi (se si controllano tutte le altre differenze tra le lingue), perché se usati con saggezza, riducono i tempi di debug, rilevando errori nella fase di compilazione, dove sono più veloci da correggere.

L'unica metrica che è possibile utilizzare per confrontare la produttività degli sviluppatori tra le lingue è una metrica che non confronta il codice tra le lingue. Alcune lingue sono notoriamente dettagliate (COBOL per la vittoria legacy), e altri richiedono diversi passaggi per fare qualcosa che puoi fare in una riga di codice (assembly vs. praticamente tutto il resto). Anche se si confrontano solo le righe di codice attive (ovvero non si contano le dichiarazioni e si contano solo i codici che comportano qualche azione) è comunque possibile distorcere i risultati.

Potresti essere in grado di argomentare in merito ai tassi di variazione. Vale a dire righe di codice aggiunte, confrontando l'inclinazione della produttività nello stesso periodo di tempo. Tuttavia, ciò non tiene conto delle modifiche negative nelle righe di codice. Ad esempio, erediti un progetto che ha il codice copia e incolla ovunque. Esegui alcuni refactoring facili e veloci per ridurre il numero di blocchi di codice ripetuti - per definizione hai una pendenza negativa.

In tutta serietà, confrontare la produttività di squadre / lingue non ha senso perché ci sono così tanti fattori aggiuntivi che influenzano la produttività di una squadra che non è possibile trarne conclusioni significative.

Ho lavorato a un progetto in cui l'infrastruttura era molto fragile e gli strumenti erano obsoleti. Il progetto è stato creato su Java con un'app a pagina singola inserita su di esso, ma ospitato in un contenitore portlet senza alcun vantaggio apparente. Il tempo impiegato per fare anche semplici cambiamenti è stato ridicolmente lungo. Se dovessi basare tutte le tue conclusioni su quel particolare progetto, potresti concludere che Java era cattivo o che le app a pagina singola erano cattive. Né sono vere. Il sistema che il brutto progetto avrebbe dovuto sostituire era costruito su C # e WebForms. Quando abbiamo sviluppato il caso aziendale per estendere l'applicazione esistente per gestire le esigenze dei clienti, la nostra produttività è salita alle stelle. Ciò significa che un'app WebForms strettamente accoppiata è superiore? Puoi solo trarre una conclusione per questo caso particolaree non si estende al mondo in generale. E ha senso solo perché esisteva un'applicazione esistente con maturità sufficiente da estendere.

Anche il confronto delle percentuali di risoluzione degli elementi nel sistema di tracciamento dei problemi è errato nel senso che si stanno confrontando infrastrutture di progetto complete tra loro. Le librerie e i framework utilizzati possono accelerare o rallentare i progressi. Potresti essere nella fase di avvio con un'inerzia molto piccola da superare, in cui il progetto in cui sei "migliore" si trova in una fase di manutenzione in cui il numero di nuovi biglietti è relativamente basso. Non si tratta mai di confrontare cose simili.