Devo usare TDD e BDD se il mio progetto sta cambiando velocemente?

C'è una differenza tra prototipi e codice scritto con l'obiettivo da eseguire in produzione.

• I prototipi sono fatti per testare rapidamente un concetto. La qualità del codice, la sicurezza, la manutenibilità non contano. Ciò che conta è terminare rapidamente il software per ottenere i risultati (cioè se le idee dietro sono valide) il prima possibile.

• Il codice di produzione dovrebbe essere più testato e più affidabile, facile da mantenere, sicuro, ecc. Se sacrifichi la qualità del codice, l'architettura o i test per eseguire l'operazione più rapidamente, ti farà male prima o poi . In sostanza, non spendendo un'ora a testare il tuo codice ora ti costerà (o i tuoi colleghi) giorni dopo, a causa di uno strano bug che avresti potuto catturare facilmente se stavi testando il tuo codice.

Se il tuo intento è di usare il codice più tardi, scrivilo come ci si aspettava che vivesse per sempre. Ignora i test solo se sai, di sicuro, che il codice verrà gettato via molto presto (presto: tra qualche settimana).

È un compromesso, tuttavia, nella maggior parte dei casi la risposta è, sì , dovresti usare TDD (o BDD).

Studi mostrano che il TDD può causare un aumento del tempo iniziale di sviluppo ma la riduzione del numero di difetti supera questo valore.

Rilevare i difetti in seguito aggiunge sostanzialmente al costo di sviluppo. TDD ti offre un feedback più rapido e ti consente di identificare i difetti il più vicino possibile alla scrittura del codice.

TDD offre anche una serie di altri vantaggi (se applicati correttamente).

• Incoraggia un codice più liberamente accoppiato, poiché il codice strettamente accoppiato è più difficile da testare.
• Evidenzia le violazioni di SRP, poiché le responsabilità extra aggiungono una dimensione extra al test, indicando un'esplosione combinatoria nel numero di test.
• Facilita la programmazione delle coppie, vedi Programmazione Ping Pong .

Va bene - con condizioni. Penso che la tua domanda possa essere riformulata semplicemente: "è corretto assumere debito tecnico ?"

vale a dire. Va bene produrre le cose in modo rapido e sporco quando altri fattori lo richiedono?

A cui la risposta un po 'lanosa è "sì, a volte - a patto che paghi i tuoi debiti" .

Ci sono ulteriori sfumature nella tua domanda. Ad esempio se TDD ti rallenterà davvero tanto. Direi che, supponendo che tu sappia già come fare TDD e come usare questi strumenti, non ti rallenterà affatto. Ti costringerà a prendere decisioni di progettazione che avresti comunque incontrato e probabilmente ti aiuterà a risolverli più rapidamente. Se, d'altro canto, ti ci vorrà del tempo per imparare la metodologia e gli strumenti, allora potrebbe non essere plausibile tener conto anche di tutto quel tempo di apprendimento.

Il secondo è se quegli altri fattori davvero richiedono di assumere debiti tecnici. Startup e nuovi prodotti sono un habitat naturale per il debito tecnico. Se non ottenere qualcosa in un dato momento significa andare fuori mercato, allora è meglio assumere un debito tecnico. Se assumersi un debito tecnico significa che il prototipo della tua auto che guida potrebbe bloccarsi, è meglio ritardare il rilascio. Non credo che il debito tecnico debba di fatto essere la prima cosa a rispettare una scadenza ravvicinata: il richiamo agli stakeholder per una pubblicazione ritardata (o lo stesso ambito di data diversa) dovrebbe essere la prima opzione, quando possibile.

Infine, sei sicuro che pagherai il tuo debito in modo tempestivo? Sei veramente veramente sicuro? È fin troppo facile cedere a fattori esterni (non sembrano mai andare via) e alla fine si arriva a un punto in cui tutto ciò che si sta facendo è pagare gli interessi sul proprio debito.

Se è necessario compromettere i test, è possibile provare a identificare i bit in cui i risultati errati sono meno importanti. Ma dovresti sforzarti di avere tutto il codice che puoi testare, prima di impegnarti nella tua linea principale di controllo della versione.

Ovviamente puoi sacrificare i test e affrontare i problemi che potrebbero causare ulteriori problemi. Potresti fare qualche prototipo di nuovo codice al di fuori del controllo di versione, a condizione che non prenda MAI la produzione, per capire quale sia la direzione giusta.