Il TDD ha portato a un buon design? [duplicare]

Dall'esperienza:

TDD non porta necessariamente a un buon design. È possibile e davvero facile ottenere un programma mal progettato usando TDD.

TDD è solo uno strumento per aiutarci a progettare più rapidamente utilizzando il refactoring , non farà mai apparire magicamente il design del programma. TDD è uno strumento di aiuto alla progettazione. La qualità del design che otterrete da TDD dipende in gran parte dalla capacità dello sviluppatore di utilizzare il refactoring per progettare modelli o di rifattorizzare i principi SOLID.

Lo sviluppatore farà emergere il progetto usando il refactoring continuo. È l'aspetto più importante di TDD: Refactoring .

Applicare il TDD senza fare refactoring costante porterà spesso a sistemi progettati in modo scadente, il che è peggio dell'applicazione del BDUF.

Il TDD è spesso associato alla nozione di " design emergente ". In modo agile, spesso crei il tuo software in modo incrementale, funzione per caratteristica. Quindi non puoi sapere fin dall'inizio quale architettura ti servirà, si evolverà / emergerà con il tempo. Quindi ogni volta che aggiungi una nuova funzionalità, esegui dei refactoring per migliorare il design della tua applicazione. È un design continuo / incrementale. Ecco perché TDD è la chiave di un processo agile.

BDUF non è incompatibile con TDD. Non c'è niente di sbagliato nell'iniziare un pezzo di software avendo già in mente il design. TDD ti consentirà quindi di implementare rapidamente il progetto. E nel caso in cui il progetto che hai pensato fosse sbagliato, TDD ti permetterà di effettuare il refactoring in modo corretto e sicuro. Ancora una volta, è solo uno strumento, è lì per aiutarci a sviluppare le nostre idee più velocemente e progettare roba in modo sicuro e veloce.

Quindi puoi fare BDUF + TDD o Emergent Design + TDD, più tardi è il più comune nella comunità agile a causa del modo iterativo di lavorare.

In tutti i casi non dovresti mai provare a fare progetti emergenti senza essere disposti a fare un costante refactoring, entrambi vanno insieme e richiede davvero molta disciplina. Le cose possono rapidamente fuori controllo se continui ad aggiungere nuove funzionalità senza applicare Refactoring.

Il refactoring si applica sia al codice di produzione che al codice di test.

Un interessante articolo da leggere per ottenere maggiori informazioni sulla domanda può essere trovato qui:

Apprendimento dai risolutori di Sudoku

Tutto dipende da come stanno pensando i tuoi programmatori:

1. Se hanno già utilizzato TDD in precedenza, c'è una possibilità di ottenere un buon design
2. Se TDD viene imposto dall'esterno, allora può solo rompere il modello esistente che i tuoi programmatori stanno utilizzando con facilità
3. D'altro canto, il team dovrebbe utilizzare modelli comuni in modo che tutti possano creare parte dello stesso progetto invece di andare casualmente in direzioni diverse

Quindi è un equilibrio tra il modo in cui il processo dirompente si vuole imporre e quanto si può credere ai programmatori di utilizzare le proprie tecniche per creare il miglior design possibile. Ottenere un feedback su quanto è stato rotto il codice precedente è una metrica di buona qualità per i programmatori.

Sicuramente, TDD porta al design migliore , il TDD porta alla qualità del codice migliore , il TDD porta alla migliore manutenibilità del codice.

Ma TDD non aiuta a creare codice privo di bug, nello stesso modo in cui non fornisce un buon design.

Per me TDD è il modo per risolvere il problema un po 'più velocemente, il gioco è fatto. Forse perché sono un cattivo pensatore iniziale. È più facile per me iniziare con alcune idee e modellarlo con i test un po 'più tardi.

TDD non garantisce un buon design alla fine della giornata. Come hai detto, il "Gioco della vita" potrebbe essere un grande esempio. Ho implementato una volta con puro TDD. Tutto è stato fantastico non appena ho avuto un sacco di test unitari. Ma dopo aver implementato un'interfaccia utente e aver provato a eseguire il gioco su una griglia 64x64, si è scoperto che le prestazioni dell'applicazione erano completamente risucchiate. Ciò significava che avevo il 100% di copertura del codice, ma l'app non sarebbe volata in produzione . Questo caso potrebbe facilmente essere proiettato su alcuni progetti che lavoriamo in ufficio.

Quindi, preferisco un altro approccio. Chiamiamolo post-prototype design. Non appena ho qualche codice funzionante con TDD (o meno) comincio a capire meglio il compito, inizio a vedere diversi modi di implementazione. Potrei passare un po 'di tempo con un pezzo di carta per trovare alcune idee di design. Successivamente posso avviare l'attività da zero o riutilizzare i test di unità già creati per implementare tali idee.