Sono nel mio primo vero lavoro come programmatore e quello che vedo è solo il codice "Big Ball of Mud" (anche senza commenti utili), ma mi piace fare il codice pulito, ed è davvero difficile per me programmare in un modo peggiore.
Sto cercando un caso di studio in cui l'uso del codice pulito (vedo qui diverse definizioni di cosa sia il codice pulito) ha migliorato lo sviluppo e la manutenibilità.
Un rapido (ma per nulla esaustivo) ricerca di Google Scholar presenta molti articoli che si riferiscono a Pulisci codice , ma non ho visto personalmente documenti che coprano una correlazione tra "codice pulito" "e sviluppo migliorato.
Tuttavia, pensa alla tua domanda per un momento. Ti stai chiedendo di migliorare lo sviluppo, e questo di per sé è un argomento molto ampio coperto non semplicemente dalla scrittura di codice migliore, ma anche da molti altri fattori come la comunicazione, la gestione delle aspettative, la metodologia e i processi di ottimizzazione, test, integrazione continua e tutta la scatola e i dadi se si considera solo quante cose vanno a far sì che un progetto di sviluppo software abbia successo, figuriamoci migliorarlo.
Quindi la tua domanda dovrebbe probabilmente essere: la scrittura di codice pulito contribuisce a migliorare lo sviluppo del software? Per rispondere, l'unica "prova" che potrei fornire sarebbe del tutto aneddotica, e per questo penso il Clean Code libro sarebbe un eccellente riferimento, in quanto è scritto non solo da Bob Martin stesso, ma anche con molti capitoli di alcuni tra i più intelligenti sviluppatori di software. Se questo non aiuta, allora forse potrebbe applicarsi una piccola e fredda logica.
Se crei disordine nella tua casa e non riesci mai a pulirlo, vivere in casa diventerà un lavoro ingrato. Diventa più difficile trovare le cose, più difficile muoversi, e nessuno sano di mente vorrà visitarti se vivi in un ambiente sudicio. Lo stesso anche con il codice. Se il tuo codice è un disastro, trovi più difficile individuare i problemi, figuriamoci correggerli. Diventa più facile giustificare un work-around che potrebbe non svolgere il lavoro, ma hey, sicuramente è meglio battere tutto quel vecchio lascito ereditario, giusto? Alla fine, proprio come non mettere mai in ordine la tua casa, lasciare che il tuo codice diventi disordinato ti costerà tempo e fatica e ti creerà difficoltà a lungo termine. Mantenere il tuo codice pulito ti fornirà comunque una piattaforma migliore per lavorare, effettuare il refactoring e il debugging meno di un lavoro di routine, e ti richiederà di preoccuparti meno spesso se sarai in grado di mantenere il tuo codice facilmente nel tempo.
No, non ho prove dirette per darti, e questi sono solo i pensieri di qualcuno che ha fatto queste cose per un tempo molto lungo, e che si spera abbia guadagnato un po 'di saggezza sviluppo del software lungo la strada. : -)
Quello che devi capire è che nessuna azienda si propone di scrivere codice mediocre. Il problema è che il 50% del codice, dare o prendere, è scritto dai programmatori sotto la media della tua azienda. Stai predicando al coro quando esponi i benefici del codice pulito. Il trucco è come farlo. Esegui ricerche su strumenti come peer review, analisi statica, test automatici, integrazione continua, TDD, mischia, programmazione estrema, ecc. E presenti potenziali soluzioni invece di spiegare perché il problema è negativo.
So che questo andrà contro le avversità qui, ma il time-to-market, i requisiti giusti, il giusto finanziamento, il buon marketing, il giusto prezzo e la buona fortuna hanno molta più influenza sul successo dei prodotti software rispetto alla qualità del codice .
Questo è NON per dire che la qualità del codice dovrebbe essere ignorata, ma dovresti riconoscere che è solo uno dei tanti fattori.
Ci sono molti esempi di codice semplicemente orribile in prodotti di grande successo (ad esempio il sistema operativo Apple originale che ha lasciato la gestione dei thread alle applicazioni).
Non riesco a pensare ad alcun esempio di codice bello che superi un prodotto mal concepito o troppo costoso.
Quindi, se il suo time to market e il suo bel codice, il time to market dovrebbe avere la priorità!
Devi separare il codice pulito dagli obiettivi reali: ridurre i costi di correzione dei difetti dopo l'implementazione e ridurre inutili rilavorazioni. Quando parli di "scrivere codice pulito per far sì che abbia meno bug", stai parlando di religione. Quando parli di "ridurre il tasso di difetti del 10% risparmiando 2 mesi / uomo di sforzi sul progetto", stai parlando di gestione. Il codice pulito è uno strumento per migliorare la qualità iniziale del codebase e quindi ridurre il costo totale, ma è uno dei tanti.
Il seguente documento spiega perché farlo bene la prima volta conta da un punto di vista dei costi: link
Non sono a conoscenza di nessuno studio specifico, ma controlla il lavoro di Steve McConnell .
Se qualcuno lo ha, lo farà. Ad esempio una scansione di due minuti ha trovato questo (16 anni ma è ancora attuale).
Per aggiungere alla risposta di mattnz, se non lo hai già, direi esplicitamente di dare un'occhiata al codice completo: un manuale pratico di Software Construction di Steve McConnell. Oltre al fatto che probabilmente migliorerà la tua codifica, cita numerosi studi in tutto il libro su come le varie pratiche di codifica influenzano la qualità dei programmi.
Come esempio (dal libro):
Another study of a different 450 routines (which is just an unusual coincidence) found that routines with the highest coupling-to-cohesion ratios had 7 times as many errors as those with the lowest coupling-to-cohesion ratios and were 20 times as costly to fix (Selby and Basili 1991).
Inoltre era la risposta numero uno alla domanda Qual è il singolo libro più influente che ogni programmatore dovrebbe leggere? (anche se vedo che le risposte a questa domanda sono state recentemente riorganizzate in modo zoppo)
Leggi altre domande sui tag clean-code case-studies