Esiste una correlazione tra complessità del codice e produttività degli sviluppatori?

10

Il tempo impiegato per il refactoring di una base di codice vale la pena a lungo termine, in termini di produttività degli sviluppatori?

Mi sembra abbastanza chiaro che modificare un sistema pulito e ben progettato è molto più semplice e veloce rispetto a lavorare su uno mal progettato, ma sto cercando alcune prove concrete. Ci sono studi su questo argomento?

productivity complexity

— Benny Hallett
fonte

Vedi RICOSTRUZIONE

— hakre,

1

Inizia a mantenere un pasticcio da solo e diventa il giudice.

— Tulains Córdova,

16

Empiricamente, i software con metriche di maggiore complessità, come la complessità ciclomatica, sono più difficili da mantenere. Esistono ricerche a sostegno di questo fatto risalente agli anni '70 ("Complessità del programma e produttività del programmatore", ET Chen) . C'è anche lavoro che suggerisce che la densità della complessità, che è la complessità ciclomatica rispetto alle dimensioni del sistema, si riferisce anche ai tempi di manutenzione ("Densità della complessità ciclomatica e produttività della manutenzione del software", GK Gill, CF Kemerer) , che è disponibile anche qui gratuitamente . Sfortunatamente, è necessario un abbonamento IEEE al documento di Chen, ma puoi provare a cercarlo su altre fonti se sei interessato.

Dal punto di vista della qualità, spesso vale la pena dedicare un po 'di tempo al refactoring, supponendo che sia in atto un framework di test per impedire l'introduzione di nuovi difetti. Ciò ti consentirà di implementare più facilmente nuove funzionalità nel tuo sistema, aggiungere ulteriori test e addestrare i nuovi sviluppatori a lavorare.

Alla fine, tuttavia, c'è la pressione di offrire nuove funzionalità e valore aggiunto. È necessario bilanciare il refactoring con l'implementazione di nuove funzionalità e la riparazione dei difetti.

— Thomas Owens
fonte

2

un altro punto da aggiungere è che quando si esegue il refactoring, è probabile che si implementino anche le funzionalità in un modo migliore / più efficiente / più pulito. C'è un adagio che ho sentito una miriade di volte per l'effetto di "tra 5 anni farai rabbrividire che pensavi che il tuo codice fosse" buono ""

— warren,

1

@hakre Ho controllato quando ho pubblicato questo e di nuovo ora, utilizzando sia una ricerca Web di Google che Google Scholar. All'epoca in cui avevo scritto questo post, nessuno dei due documenti era disponibile senza l'acquisto. Tuttavia, da allora, un articolo è stato pubblicato su un dominio dell'Università di Pittsburgh che sembra appartenere a uno degli autori e ho aggiunto un link ad esso. L'altro documento non è disponibile gratuitamente. Ho aggiunto i titoli al corpo del post per renderli leggermente più facili. Se non vuoi leggere i documenti, dovrai accettare la mia analisi, unita alla mia conoscenza ed esperienza.

— Thomas Owens

0

Sto cercando alcune prove concrete

Quindi smetti di perdere tempo qui.

Trova un codice costoso da mantenere. È facile. Guarda i ticket sui problemi della tua organizzazione.
Trova un codice economico da mantenere. Trova il codice che viene eseguito frequentemente, ma ha pochi o nessun ticket problematico.
Misura la complessità con uno qualsiasi degli strumenti di complessità ampiamente disponibili.
Crogiolarsi nelle prove.

Ora hai fornito numeri per confermare l'ovvio.

— S. Lott
fonte

5

Non proprio. la complessità dell'attività svolta dal software deve essere distinta dalla complessità aggiunta causata dall'implementazione scelta.

— reinierpost,

4

-1 non una risposta

— Dave Hillier,