Questa limitazione di Test Driven Development (e Agile in generale) è praticamente rilevante?

In Test Driven Development (TDD) si inizia con una soluzione non ottimale e quindi si producono in modo iterativo quelli migliori aggiungendo casi di test e refactoring. I passaggi dovrebbero essere piccoli, il che significa che ogni nuova soluzione si troverà in qualche modo nelle vicinanze di quella precedente.

Questo assomiglia a metodi matematici di ottimizzazione locale come la discesa del gradiente o la ricerca locale. Una limitazione ben nota di tali metodi è che non garantiscono di trovare l'ottimale globale, o addirittura un accettabile locale ottimale. Se il tuo punto di partenza è separato da tutte le soluzioni accettabili da una vasta regione di soluzioni sbagliate, è impossibile arrivarci e il metodo fallirà.

Per essere più specifici: sto pensando a uno scenario in cui hai implementato una serie di casi di test e poi scopri che il prossimo caso di test richiederebbe un approccio diversamente diverso. Dovrai buttare via i tuoi lavori precedenti e ricominciare da capo.

Questo pensiero può effettivamente essere applicato a tutti i metodi agili che procedono a piccoli passi, non solo a TDD. Questa proposta di analogia tra TDD e ottimizzazione locale ha qualche grave difetto?

Una limitazione ben nota di tali metodi è che non garantiscono di trovare l'ottimale globale, o addirittura un accettabile locale ottimale.

Per rendere il confronto più adeguato: per alcuni tipi di problemi, è molto probabile che gli algoritmi di ottimizzazione iterativa producano una buona optima locale, per alcune altre situazioni, possono fallire.

Sto pensando a uno scenario in cui hai implementato una serie di casi di test e poi scopri che il prossimo caso di test richiederebbe un approccio diversamente diverso. Dovrai buttare via i tuoi lavori precedenti e ricominciare da capo.

Posso immaginare una situazione in cui ciò può accadere nella realtà: quando si sceglie l'architettura sbagliata in un modo, è necessario ricreare di nuovo tutti i test esistenti da zero. Supponiamo che inizi a implementare i tuoi primi 20 casi di test nel linguaggio di programmazione X sul sistema operativo A. Sfortunatamente, il requisito 21 include che l'intero programma deve essere eseguito sul sistema operativo B, dove X non è disponibile. Pertanto, è necessario eliminare la maggior parte del lavoro e la reimplementazione nella lingua Y. (Ovviamente, non si eliminerebbe completamente il codice, ma lo si trasferirà nella nuova lingua e sistema.)

Questo ci insegna, anche quando si utilizza TDD, è una buona idea fare prima qualche analisi generale e progettazione. Questo, tuttavia, è vero anche per qualsiasi altro tipo di approccio, quindi non lo vedo come un problema intrinseco di TDD. E, per la maggior parte delle attività di programmazione del mondo reale, puoi semplicemente scegliere un'architettura standard (come il linguaggio di programmazione X, il sistema operativo Y, il sistema di database Z sull'hardware XYZ) e puoi essere relativamente sicuro che una metodologia iterativa o agile come TDD non ti porterà in un vicolo cieco.

Citando Robert Harvey: "Non è possibile far crescere un'architettura dai test unitari". O pdr: "TDD non solo mi aiuta a raggiungere il miglior progetto finale, mi aiuta ad arrivarci in meno tentativi."

Quindi in realtà quello che hai scritto

Se il tuo punto di partenza è separato da tutte le soluzioni accettabili da una vasta regione di soluzioni sbagliate, è impossibile arrivarci e il metodo fallirà.

potrebbe diventare vero: quando si sceglie un'architettura sbagliata, è probabile che non si raggiunga la soluzione richiesta da lì.

D'altra parte, quando si esegue in anticipo una pianificazione generale e si sceglie l'architettura giusta, utilizzare TDD dovrebbe essere come avviare un algoritmo di ricerca iterativo in un'area in cui ci si può aspettare di raggiungere il "massimo globale" (o almeno un massimo abbastanza buono ) in pochi cicli.

Non penso che TDD abbia un problema di massimi locali. Il codice che scrivi potrebbe, come hai notato correttamente, ma è per questo che è attivo il refactoring (riscrittura del codice senza cambiare funzionalità). Fondamentalmente, con l'aumentare dei test, è possibile riscrivere porzioni significative del modello a oggetti se necessario mantenendo il comportamento invariato grazie ai test. I test affermano verità invarianti sul tuo sistema che, pertanto, devono essere valide sia in termini massimi locali che assoluti.

Se sei interessato a problemi legati al TDD, posso menzionarne tre diversi a cui penso spesso:

1. Il problema della completezza : quanti test sono necessari per descrivere completamente un sistema? La "codifica per casi esemplificativi" è un modo completo per descrivere un sistema?

2. Il problema della tempra : qualunque sia il test di interfaccia, deve avere un'interfaccia immutabile. I test rappresentano verità invarianti , ricorda. Sfortunatamente queste verità non sono affatto conosciute per la maggior parte del codice che scriviamo, nella migliore delle ipotesi solo per oggetti rivolti verso l'esterno.

3. Il problema del danno di prova : per rendere verificabili le asserzioni, potrebbe essere necessario scrivere un codice non ottimale (meno performante, ad esempio). Come possiamo scrivere i test in modo che il codice sia buono come può essere?

Modificato per rispondere a un commento: ecco un esempio di modifica del massimo locale per una funzione "doppia" tramite refactoring

Test 1: quando l'ingresso è 0, restituisce zero

Implementazione:

function double(x) {
  return 0; // simplest possible code that passes tests
}

Refactoring: non necessario

Test 2: quando l'ingresso è 1, restituisce 2

Implementazione:

function double(x) {
  return x==0?0:2; // local maximum
}

Refactoring: non necessario

Test 3: quando l'ingresso è 2, restituisce 4

Implementazione:

function double(x) {
  return x==0?0:x==2?4:2; // needs refactoring
}

refactoring:

function double(x) {
  return x*2; // new maximum
}

Quello che stai descrivendo in termini matematici è ciò che chiamiamo dipingere te stesso in un angolo. Questo evento non è certo esclusivo di TDD. In cascata puoi raccogliere e riversare i requisiti per mesi sperando di poter vedere il massimo globale solo per arrivarci e realizzare che esiste un'idea migliore solo la collina successiva.

La differenza è in un ambiente agile che non ti saresti mai aspettato di essere perfetto a questo punto, quindi sei più che pronto a lanciare la vecchia idea e passare alla nuova idea.

Più specifico per TDD, esiste una tecnica per impedire che ciò accada a te quando aggiungi funzionalità in TDD. È la premessa per la trasformazione . Laddove TDD ha un modo formale per il refactoring, questo è un modo formale per aggiungere funzionalità.

Nella sua risposta , @Sklivvz ha sostenuto in modo convincente che il problema non esiste.

Voglio sostenere che non importa: la premessa fondamentale (e ragion d'essere) delle metodologie iterative in generale e Agile e in particolare TDD in particolare, è che non solo l'ottimale globale, ma anche gli ottimum locali non lo so. Quindi, in altre parole: anche se quello fosse un problema, non c'è modo di aggirarlo comunque nel modo iterativo. Supponendo che accetti la premessa di base.

Le pratiche TDD e Agile possono promettere di produrre una soluzione ottimale? (O anche una soluzione "buona"?)

Non esattamente. Ma non è questo il loro scopo.

Questi metodi forniscono semplicemente un "passaggio sicuro" da uno stato a un altro, riconoscendo che i cambiamenti richiedono tempo, sono difficili e rischiosi. E il punto di entrambe le pratiche è garantire che l'applicazione e il codice siano entrambi fattibili e comprovati per soddisfare i requisiti più rapidamente e più regolarmente.

... [TDD] si oppone allo sviluppo del software che consente di aggiungere software che non ha dimostrato di soddisfare i requisiti ... Kent Beck, a cui è stato accreditato di aver sviluppato o "riscoperto" la tecnica, ha dichiarato nel 2003 che TDD incoraggia semplici progetta e ispira fiducia. ( Wikipedia )

TDD si concentra sul garantire che ogni "blocco" di codice soddisfi i requisiti. In particolare, aiuta a garantire che il codice soddisfi i requisiti preesistenti, anziché consentire ai requisiti di essere guidati da una codifica scadente. Tuttavia, non promette che l'implementazione sia "ottimale" in alcun modo.

Per quanto riguarda i processi Agile:

Il software di lavoro è la misura principale del progresso ... Alla fine di ogni iterazione, le parti interessate e il rappresentante del cliente esaminano i progressi e rivalutano le priorità al fine di ottimizzare il ritorno sull'investimento ( Wikipedia )

L'agilità non è alla ricerca di una soluzione ottimale ; solo una soluzione funzionante , con l'intento di ottimizzare il ROI . Promette una soluzione funzionante prima piuttosto che dopo ; non "ottimale".

Ma va bene, perché la domanda è sbagliata.

Gli ottimali nello sviluppo del software sono obiettivi sfocati e mobili. I requisiti di solito sono in evoluzione e pieni di segreti che emergono, con tuo grande imbarazzo, in una sala conferenze piena di capi del tuo capo. E la "bontà intrinseca" dell'architettura e della codifica di una soluzione è classificata dalle opinioni divise e soggettive dei tuoi pari e da quella del tuo superiore manageriale - nessuno dei quali potrebbe effettivamente sapere qualcosa sul buon software.

In meno, pratiche TDD e agile riconoscono le difficoltà e tentare di ottimizzare per due cose che sono oggettivi e misurabili: . Lavoro V non-lavoro e Sooner v tardi..

E, anche se abbiamo "lavoro" e "prima" come metriche oggettive, la tua capacità di ottimizzare per loro dipende principalmente dall'abilità e dall'esperienza di una squadra.

Le cose che si potrebbe interpretare come gli sforzi producono ottime soluzioni includono cose come:

• Principi solidi
• Codice pulito
• Modelli di progettazione
• Assumere persone qualificate ed esperte ...

eccetera..

_{Se ciascuna di queste cose effettivamente produca soluzioni ottimali sarebbe un'altra grande domanda da porre!}

Una cosa che nessuno ha aggiunto finora è che lo "Sviluppo TDD" che stai descrivendo è molto astratto e irrealistico. Potrebbe essere così in un'applicazione matematica in cui si sta ottimizzando un algoritmo, ma ciò non accade molto nelle applicazioni aziendali su cui la maggior parte dei programmatori lavora.

Nel mondo reale i tuoi test sostanzialmente esercitano e convalidano le regole aziendali:

Ad esempio - Se un cliente è un non fumatore di 30 anni con una moglie e due figli, la categoria premium è "x" ecc.

Non modificherai iterativamente il motore di calcolo premium fino a quando non sarà corretto per molto tempo - e quasi certamente non mentre l'applicazione è attiva;).

Quello che hai effettivamente creato è una rete di sicurezza in modo che quando viene aggiunto un nuovo metodo di calcolo per una particolare categoria di clienti, tutte le vecchie regole non si rompano improvvisamente e non forniscano la risposta sbagliata. La rete di sicurezza è ancora più utile se il primo passo del debug è creare un test (o una serie di test) che riproduca l'errore prima di scrivere il codice per correggere il bug. Quindi, un anno dopo, se qualcuno ricrea accidentalmente il bug originale, il test unitario si interrompe prima ancora che il codice venga archiviato. Sì, una cosa che TDD consente è che ora puoi fare un grande refactoring e riordinare le cose con fiducia ma non dovrebbe essere una parte enorme del tuo lavoro.

Non penso che si frapponga. La maggior parte dei team non ha nessuno in grado di trovare una soluzione ottimale anche se l'hai scritta sulla lavagna. TDD / Agile non si frapporranno.

Molti progetti non richiedono soluzioni ottimali e quelli che lo fanno, il tempo, l'energia e la concentrazione necessari saranno realizzati in questo settore. Come ogni altra cosa che tendiamo a costruire, in primo luogo, farlo funzionare. Quindi fallo veloce. Potresti farlo con una sorta di prototipo se le prestazioni sono così importanti e quindi ricostruire il tutto con la saggezza acquisita attraverso molte iterazioni.

Sto pensando a uno scenario in cui hai implementato una serie di casi di test e poi scopri che il prossimo caso di test richiederebbe un approccio diversamente diverso. Dovrai buttare via i tuoi lavori precedenti e ricominciare da capo.

Questo potrebbe accadere, ma è più probabile che accada è la paura di cambiare parti complesse dell'applicazione. Non avere alcun test può creare un maggiore senso di paura in questo settore. Uno dei vantaggi di TDD e avere una serie di test è che hai creato questo sistema con l'idea che dovrà essere cambiato. Quando trovi questa soluzione monolitica ottimizzata sin dall'inizio, può essere molto difficile cambiare.

Inoltre, inseriscilo nel contesto della tua preoccupazione per l'ottimizzazione insufficiente e non puoi fare a meno di passare il tempo a ottimizzare le cose che non dovresti avere e a creare soluzioni inflessibili perché eri così iper-concentrato sulle loro prestazioni.

Può essere ingannevole applicare un concetto matematico come "ottimale locale" alla progettazione del software. L'uso di tali termini rende lo sviluppo del software molto più quantificabile e scientifico di quanto non sia in realtà. Anche se esistesse "ottimale" per il codice, non abbiamo modo di misurarlo e quindi non abbiamo modo di sapere se lo abbiamo raggiunto.

Il movimento agile fu in realtà una reazione contro la convinzione che lo sviluppo del software potesse essere pianificato e previsto con metodi matematici. Nel bene e nel male, lo sviluppo del software è più un mestiere che una scienza.