Esiste un case study che dimostra in modo convincente che il codice pulito ha migliorato lo sviluppo? [chiuso]

Sono nel mio primo vero lavoro come programmatore e quello che vedo è solo il codice "Big Ball of Mud" (senza anche commenti utili), ma mi piace fare codice pulito, ed è davvero difficile per me scrivere in un peggio modo.

Sto cercando un caso di studio in cui l'uso del codice pulito (vedo qui varie definizioni di cos'è il codice pulito) ha migliorato lo sviluppo e la manutenibilità.

Una rapida (ma per nulla esaustiva) ricerca di Google Scholar rivela molti articoli che fanno riferimento al codice pulito di Bob Martin , ma non ho visto personalmente alcun documento che copra una correlazione tra "codice pulito" e miglioramento dello sviluppo.

Tuttavia, pensa alla tua domanda per un momento. Stai chiedendo di migliorare lo sviluppo e che di per sé è un argomento molto ampio trattato non solo scrivendo un codice migliore, ma anche da molti altri fattori come la comunicazione, la gestione delle aspettative, la metodologia e la semplificazione dei processi, i test, l'integrazione continua e davvero l'intera scatola e dadi quando si considera quante cose vanno nel rendere un progetto di sviluppo software di successo, per non parlare di migliorarlo.

Quindi la tua domanda dovrebbe essere: scrivere codice pulito contribuisce a migliorare lo sviluppo del software? Per rispondere a ciò, l'unica "prova" che potrei fornire sarebbe del tutto aneddotica, e per questo penso che il libro Clean Code sarebbe un riferimento eccellente, poiché è stato scritto non solo dallo stesso Bob Martin, ma anche con molti capitoli che hanno contribuito da alcuni dei più intelligenti sviluppatori di software là fuori. Se ciò non aiuta, forse potrebbe applicarsi un po 'di logica fredda e rigida.

Se fai un casino in casa e non riesci mai a pulirlo, vivere in casa diventerà un lavoro ingrato. È più difficile trovare le cose, più difficile muoversi e nessuno nella loro mente giusta vorrà visitarti se vivi in ​​un ambiente sporco. Lo stesso vale per il codice. Se il tuo codice è un disastro, trovi più difficile individuare i problemi, e tanto meno risolverli. Diventa più facile giustificare un aggiramento che potrebbe non fare il lavoro, ma ehi, è certo che è meglio battere tutto quel vecchio fango ereditato, 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 crea difficoltà a lungo termine. Mantenere pulito il codice, tuttavia, ti fornirà una piattaforma migliore in cui lavorare, rendere il refactoring e il debug meno complicati,

No, non ho prove dirette da darti, e questi sono solo i pensieri di qualcuno che ha fatto queste cose per molto tempo e che si spera abbia guadagnato un po 'di saggezza nello sviluppo del software lungo la strada. :-)

Quello che devi capire è che nessuna azienda ha intenzione di scrivere codice mediocre. Il problema è che il 50% del codice, dai o dai, è scritto dai programmatori sotto la media della tua azienda. Stai predicando al coro quando esponi i vantaggi del codice pulito. Il trucco è come farlo. Fai qualche ricerca su cose come strumenti di peer review, analisi statiche, test automatizzati, integrazione continua, TDD, scrum, programmazione estrema, ecc. E presenta potenziali soluzioni invece di spiegare semplicemente perché il problema è grave.

So che questo andrà controcorrente qui, ma il time-to-market, ottenere i requisiti giusti, avere il giusto finanziamento, un buon marketing, il giusto prezzo e la buona fortuna hanno molta più influenza sul successo dei prodotti software che sulla qualità del codice.

Questo NON vuol dire che la qualità del codice dovrebbe essere ignorata, ma dovresti riconoscere che è solo uno dei molti 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 sua gestione dei thread alle applicazioni).

Non riesco a pensare a nessun esempio di bellissimo codice che vince su un prodotto mal concepito o troppo caro.

Quindi, se è tempo di immissione sul mercato rispetto a un bel codice, il tempo di immissione sul mercato dovrebbe avere la priorità!

Devi separare il codice pulito dagli obiettivi reali: ridurre i costi di correzione dei difetti dopo l'implementazione e ridurre le rilavorazioni non necessarie. Quando parli di "scrivere codice pulito per avere meno bug", stai parlando di religione. Quando parli di "ridurre il tasso di difetti del 10% risparmiando 2 mesi-uomo di sforzo sul progetto", stai parlando della direzione. Il codice pulito è uno strumento per migliorare la qualità iniziale della base di codice e quindi ridurre il costo totale, ma è uno dei tanti.

Il seguente documento spiega perché la prima volta è importante dal punto di vista dei costi: http://www.cs.umd.edu/~mvz/pub/eworkshop02.pdf

Non sono a conoscenza di studi specifici, ma dai un'occhiata al lavoro di Steve McConnell .

Se qualcuno ce l'ha, lo farà. Per esempio una scansione due minuti ha trovato questo (16 anni, ma ancora attuali).

Per aggiungere alla risposta di Mattnz, se non l'hai già detto direi nello specifico Code Complete: A Practical Handbook of Software Construction di Steve McConnell. Oltre al fatto che probabilmente migliorerà la tua codifica, cita numerosi studi nel libro su come varie pratiche di codifica influenzano la qualità dei programmi.

Ad esempio (dal libro):

Un altro studio su 450 diverse routine (che è solo una coincidenza inusuale) ha scoperto che le routine con i rapporti di accoppiamento-coesione più elevati avevano errori 7 volte maggiori rispetto a quelle con i rapporti di accoppiamento-coesione più bassi ed erano 20 volte più costose riparare (Selby e Basili 1991).

Inoltre era la risposta numero uno alla domanda Qual è il libro più influente che ogni programmatore dovrebbe leggere? (anche se vedo che le risposte a questa domanda sono state recentemente riorganizzate in modo scadente)