Processo di programmazione Pseudocodice vs. Test Driven Development

Con Test Driven Development si dovrebbe comunque essere facendo un po 'di pianificazione in principio. Dovrebbe essere in un primo momento uno sguardo alto livello a quello che stai cercando di fare. Non venire con tutti i dettagli, ma avere un'idea in parole povere di come risolvere il problema.

Poi iniziare a testare il problema. Una volta che hai il test in atto, iniziare a farlo passare. Se non è facile da fare, potrebbe essere necessario rivedere il piano iniziale. Se ci sono problemi solo rivedere. Il test non è lì per definire la soluzione è lì per consentire di apportare modifiche in modo da avere una soluzione migliore, garantendo nel contempo la stabilità.

Direi che la cosa migliore è usare TDD. La chiave è quello di rendersi conto che TDD non significa "saltare il pianificazione". TDD significa fare un po 'di pianificazione per iniziare bene, e regolare come necessario. Si può anche non essere necessario regolare.

In generale, trovo pseudocodice diventa veramente solo rilevante quando il codice necessario per risolvere il problema è molto più complicato che il codice necessario per testare la soluzione. Se questo non è il caso, non corro nelle difficoltà che descrivono come la cosa più semplice che potrebbe funzionare è di solito una soluzione accettabile per la quantità di tempo vale la pena spendere sul problema.

Se, d'altra parte, il problema è complicato, ho bisogno di pensare attraverso il modo di avvicinarsi prima di poter scrivere anche una soluzione ingenua iniziale - Ho ancora bisogno di pianificare prima di codice; pertanto, uso una combinazione di entrambi gli approcci: una descrizione inglese di quello che inizialmente scrivere, quindi un test harness, codice soluzione quindi naive, quindi perfezionamento.

Ho usato sia con Big Upfront di sviluppo, tutti e tre hanno il loro posto a seconda di temi quali la lingua, le dinamiche di gruppo e dimensioni del programma / complessità.

In linguaggi dinamici (in particolare rubino), mi raccomando TDD, vi aiuterà a catturare gli errori che altri linguaggi avrebbero catturato in fase di compilazione.

In un grande sistema, complesso, tanto più lo progetta Upfront meglio fuori di voi sarà. Sembra che quando ho progettato per un grande progetto, ogni zona che ho a mano ondulato e ha detto "questo dovrebbe essere piuttosto semplice" è stato un punto d'inciampo più avanti nel progetto.

Se si sta lavorando solo su qualcosa di piccolo in un linguaggio staticamente tipizzato, l'approccio lista è ragionevole e vi farà risparmiare un bel po 'di tempo su TDD (manutenzione test non è gratuito, anche se la scrittura dei test, in primo luogo non è troppo cattivo) - Se non ci sono le prove del sistema su cui stai lavorando, aggiungendo nei test non è sempre ammirato e si potrebbe anche trarre qualche attenzione indesiderata.

Solo perché il test viene superato, non significa che il gioco è fatto.

TDD è più caratterizzata da Rosso - Verde - Refactor .

Avere un test fornisce uno (di due) linee di porta. E 'solo il primo, insieme minimo di requisiti. Il vero obiettivo è lo stesso obiettivo come "processo di programmazione Pseudocodice" o qualsiasi disciplina del design.

Inoltre, il TDD è guidato da test, ma questo non significa guidato ciecamente da test. È possibile scorrere il test nello stesso modo di eseguire iterazioni codice. Non c'è posto per l'adesione dogmatica ad un piano muto qui. Questa una tecnica Agile - che significa adattarlo alla tua squadra e la vostra situazione.

Progettare abbastanza codice per avere un'interfaccia testabile. Progettare abbastanza prove per essere sicuri che l'interfaccia funzionerà. Progettare alcuni altri test e un po 'di implementazione fino a vedere la necessità di refactoring.

Il vero obiettivo è un buon software. TDD non può escludere "bontà".

Una tecnica non è un mandato restrittivo. A tecniche dovrebbero essere considerati come una stampella per aiutarvi a codice prodotto buono. Se fossi più intelligente, più ricco e più bello, io non bisogno di TDD. Ma dal momento che io sono così stupido come lo sono io, ho bisogno di una stampella per aiutarmi refactoring.

Per me TDD ha un asso pseudocoding proprio non si può competere con - sia aiutare astratta e pianificare lo sviluppo, ma una volta che si è finito di sviluppo nel territorio TDD avete ancora i test di unità .

AS utile un approccio CC2 descritto pseudocoding è, semplicemente non può corrispondere a quello. TDD è solo la metà circa la progettazione, è anche fornire un'impalcatura rigorosa si può evolvere il progetto in avanti da. Tuttavia non vedo alcun motivo per cui non si può pseudocodice per risolvere i problemi di set TDD.

Non devo sviluppare organicamente.
Lo pseudocodice è la mente-killer.
E 'la piccola morte che porta la memoria di progetto oblio.
Dovrò affrontare la mia metodologia '90.
Mi permetterò a passare sopra di me e attraverso di me.
E quando è andato passato mi si accende l'occhio interiore per vedere il suo percorso.
Qualora il pseudocodice è andato ci sarà TDD.
Solo unità di test rimarranno.

(Per favore non mi fiamma per questo, io sono solo la metà seria: P)

La mia squadra mescola entrambi gli approcci ed è un modo fantastico per sviluppare (almeno per noi). Abbiamo bisogno di unit test perché abbiamo un grande e complesso sistema di software. Ma la programmazione del processo pseudocodice è mani-giù il miglior approccio per la progettazione del software che ho incontrato. Per farli lavorare insieme:

• Iniziamo scrivendo nostre classi, e compilato con stub metodo completamente commentato, con ingressi e uscite.
• Usiamo codifica coppia e revisione tra pari come dialogo per affinare e validare il design, ancora solo con gli stub metodo.
• A questo punto abbiamo ora entrambi progettati nostro sistema e avere qualche codice verificabile. Quindi, andiamo avanti e scriviamo i nostri test di unità.
• Torniamo dentro e iniziare a riempire nei metodi con commenti per la logica che deve essere scritto.
• Scriviamo il codice; i test passano.

Il bello è che per il momento abbiamo effettivamente scrivere codice, la maggior parte del lavoro di implementazione è già fatto, perché gran parte di quello che noi pensiamo come implementazione è in realtà il design del codice. Anche il processo inizi sostituisce la necessità di UML - stub di classe e il metodo sono solo descrittivo, più esso sarà effettivamente utilizzato. E siamo sempre al livello appropriato di astrazione.

Ovviamente il processo non è mai davvero così lineare come ho descritto - qualche bizzarria di implementazione può significare che abbiamo bisogno di rivedere il design di alto livello. Ma in generale, per il momento in cui scriviamo unità di test il design è davvero molto stabile (a livello di metodo), quindi non è necessario per un sacco di test di riscrittura.