Il costo scandaloso di saltare TDD e recensioni di codice

Il colore dei soldi - Chris Potter (CC BY 2.0)

Aggiornamento del 26 gennaio 2019: è stato portato alla mia attenzione che l'affermazione "correggere un bug di produzione può costare 100 volte di più rispetto a correggere un bug in fase di progettazione" è apocrifo. Continuo a sostenere il ROI positivo e i poteri di risparmio di tempo del TDD, ma dovresti leggerlo come un'opinione soggettiva piuttosto che un fatto scientifico. Il nostro settore necessita di una migliore raccolta di dati sugli impatti del TDD e di altre misure di controllo della qualità. Questo sarebbe un ottimo argomento per le collaborazioni di ricerca tra università e grandi organizzazioni di software.

Negli ultimi anni ho avuto sempre più aziende che mi chiedevano di parlare dei vantaggi dello sviluppo guidato dai test (TDD) e di condividere consigli su come implementare un processo di qualità più produttivo.

TDD è il processo di scrittura di test automatizzati per garantire che il codice funzioni prima di scrivere l'implementazione. Scrivi un test, guardalo fallire (rosso), scrivi l'implementazione, guarda il test passare (verde) e refactoring se necessario. Ripeti il ​​ciclo mentre costruisci il sistema.

Il processo è stato studiato in modo approfondito e si è dimostrato molto utile per aumentare la qualità del software. Ma lo sapevi che consente anche alle organizzazioni di risparmiare molto tempo e denaro?

Uno dei motivi principali per cui i manager citano l'attesa così lunga per implementare il TDD è il costo. È comune che gli sviluppi iniziali del progetto impieghino fino al 30% in più con TDD.

Quello che quei manager devono sapere è che TDD riduce la densità dei bug di produzione del 40% - 80%, e questo fa la differenza. Un numero maggiore di bug nella produzione porta a un drammatico aumento dei costi di manutenzione.

A causa di crescenti costi esponenziali di rilavorazione, meta-lavoro (lavoro sul lavoro), passaggi di responsabilità, interruzioni e infine assistenza clienti, valutazione dei bug e manutenzione, la correzione di un bug di produzione può costare 100 volte di più rispetto alla correzione di un bug in fase di progettazione e oltre 15 volte in più rispetto alla correzione di un bug al momento dell'implementazione.

Nota: questa affermazione è stata contestata, ma non c'è dubbio che la qualità del software migliora la produttività degli sviluppatori. Vedere "L'economia della qualità del software" per una comprensione approfondita dei dati disponibili sulla qualità del software e sull'impatto che la qualità del software può avere sull'organizzazione. Abbiamo bisogno di molti più studi sulle misure di qualità del software in modo da poter prendere decisioni meglio informate su come gestire i team di sviluppo.

Costi relativi di correzione dei bug

Usando queste cifre, diamo un'occhiata ai costi relativi di un progetto immaginario con e senza TDD. Il progetto richiederà 1.000 ore di implementazione anticipata senza TDD, senza contare la manutenzione:

Nel nostro esempio immaginario, abbiamo risparmiato 623 ore di lavoro o, per un team di 4, circa un mese di sviluppo. Se paghiamo a ciascuno sviluppatore la media nazionale degli Stati Uniti ($ 95.000) e calcoliamo una media del 30% in aggiunta agli stipendi per coprire i benefici, otteniamo un risparmio di quasi $ 37.000 USD.

Naturalmente, questo è un esempio immaginario che fa molte ipotesi. Il tuo chilometraggio varierà in base a molti fattori, tra cui l'esperienza del tuo team con TDD, la presenza o l'assenza di altre misure di qualità (come la revisione del codice), ecc ...

Ecco i presupposti formulati:

  • Bug di produzione senza TDD: 100
  • Bug di produzione con TDD: 40 (60% in meno, via di mezzo tra 40% - 80%)
  • Tempo medio per la correzione del bug nella fase di implementazione (TDD): 1 ora (questo numero viene utilizzato solo per ricavare il costo di correzione del bug di produzione)
  • Tempo medio per correggere un bug di produzione: ~ 15 ore

Giocare con una di quelle variabili ovviamente altererà i risultati. Ciò che è abbastanza certo è che TDD risparmia tempo e denaro man mano che i costi di manutenzione vengono presi in considerazione - un sacco di tempo e denaro.

I risultati relativi di questo esempio immaginario mi sembrano fedeli in base alla mia esperienza con progetti di produzione reali, sia con che senza TDD.

Le recensioni di codice hanno effetti simili

Le revisioni del codice hanno effetti simili. In effetti, alcuni studi hanno scoperto che le revisioni del codice sono più efficaci del TDD. Secondo uno studio del 1988, ogni ora trascorsa nella revisione del codice consente di risparmiare 33 ore di manutenzione.

È davvero straordinario, ma i bug che catturano i benefici delle revisioni del codice non sono all'altezza della mia esperienza personale. Trovo i test automatizzati molto più utili per individuare i bug, quindi come possiamo spiegare la straordinaria efficacia delle revisioni del codice?

Condivisione della conoscenza. Quando si utilizzano revisioni del codice, il team si corregge automaticamente quando gli sviluppatori utilizzano anti-pattern e altre pratiche scadenti. Allo stesso tempo, condividono modelli efficaci, si insegnano a vicenda modi migliori per fare le cose e si insegnano a vicenda come scrivere codice più leggibile.

Il risultato netto di ciò è che i tuoi sviluppatori junior salgono rapidamente al livello degli sviluppatori più intelligenti del team e la velocità dell'intero team migliora. È difficile sopravvalutare il valore di una cultura del tutoraggio nella tua squadra.

Il costo delle interruzioni

Perché costa molto di più correggere i bug di produzione? Perché una volta che un bug raggiunge la produzione, il costo è molto più del semplice costo di correzione del bug.

La correzione di un bug in produzione è molto più costosa rispetto alla correzione di un bug durante lo sviluppo. Per comprendere l'entità della differenza, è necessario innanzitutto comprendere il costo dell'interruzione di uno sviluppatore.

Una correzione di bug di produzione spesso implica un'interruzione nel contesto e nella cadenza dello sviluppo delle funzionalità. In altre parole, gli sviluppatori vengono estratti dal contesto in cui stanno attualmente lavorando e scaricati nel contesto del bug, dove ci vuole tempo per assorbire il codice e il flusso correlati, diagnosticare una causa principale, correggere il bug e quindi riassorbire il contesto di ciò su cui stavano lavorando prima.

Ogni cambio di contesto può costare fino a 20 minuti di produttività degli sviluppatori, ma l'emorragia non si ferma qui. L'interruzione di uno sviluppatore per correggere un bug può causare più bug nel codice su cui stavano lavorando prima che fossero interrotti. Secondo Microsoft Research, un'attività interrotta richiede circa il doppio del tempo per il completamento e contiene il doppio degli errori rispetto a un'attività ininterrotta.

In altre parole, il costo per correggere i bug che vengono rilasciati in produzione non riguarda solo il costo per correggere l'errore di produzione. Le interruzioni aumentano il costo dell'attuale lavoro di sviluppo e introducono più bug che dovranno eventualmente essere corretti.

In una nota correlata, il multitasking è una pessima idea. Per essere produttivi, gli sviluppatori devono concentrarsi su una cosa alla volta.

Conclusione

La prossima volta che qualcuno ti dice che non ha il tempo o il budget per il TDD o le revisioni del codice, diglielo con fiducia, "in quel caso, davvero non hai il tempo o il budget per saltare il TDD".

Prossimi passi

Scopri meglio TDD e il suo ruolo nel processo di sviluppo del software:

  • "5 idee sbagliate comuni su TDD e test unitari"
  • "Test unitari vs funzionali vs test di integrazione"
  • "5 domande a cui deve rispondere ogni test unitario"
  • "TDD in ES6 e React Webcast"
  • Aumenta il livello del tuo team con tutoraggio: come scrivere più codice testabile, processo TDD, processo CI / CD e altro ancora

Aumenta le tue abilità con il tutoraggio live 1: 1

DevAnywhere è il modo più veloce per salire di livello con competenze JavaScript avanzate:

  • Lezioni dal vivo
  • Orari flessibili
  • Tutoraggio 1: 1
  • Crea app di produzione reali
https://devanywhere.io/

Eric Elliott è autore di "Programmazione di applicazioni JavaScript" (O’Reilly) e cofondatore di DevAnywhere.io. Ha contribuito a esperienze software per Adobe Systems, Zumba Fitness, The Wall Street Journal, ESPN, BBC e i migliori artisti discografici tra cui Usher, Frank Ocean, Metallica e molti altri.

Lavora dove vuole con la donna più bella del mondo.