Pseudo Programmering Process vs. Test Driven Development

Med testdrevet utvikling bør du likevel gjøre noen planlegging i begynnelsen. Det bør først være et høyt nivå titt på hva du prøver å gjøre. Ikke kom opp med alle detaljer, men får en idé i vanlig engelsk om hvordan å løse problemet.

Deretter begynne å teste problemet. Når du har fått testen på plass, begynner å gjøre det passere. Hvis det ikke er lett å gjøre, kan det være nødvendig å revidere den opprinnelige planen. Hvis det er problemer bare revidere. Testen er ikke der for å definere løsningen det er der for å tillate deg å gjøre endringer slik at du kan ha en bedre løsning og samtidig sikre stabiliteten.

Jeg vil si det beste alternativet er å bruke TDD. Nøkkelen er å innse at TDD ikke betyr "hoppe planleggingen". TDD betyr gjøre litt planlegging for å komme i gang også, og justere etter behov. Du kan ikke engang trenger å justere.

Vanligvis finner jeg pseudo bare virkelig blir aktuelt når koden er nødvendig for å løse problemet er mye mer komplisert at koden er nødvendig for å teste løsningen. Hvis dette ikke er tilfelle, vet jeg ikke kjøre inn i problemer du beskriver som den enkleste ting som kunne fungere er vanligvis en akseptabel løsning for tiden verdt å bruke på problemet.

Dersom, på den annen side, problemet er komplisert, jeg trenger å tenke gjennom hvordan å nærme seg det før jeg kan skrive selv en innledende naiv løsning - jeg fortsatt trenger for å planlegge før jeg kode; Derfor bruker jeg en kombinasjon av begge tilnærminger: en engelsk beskrivelse av hva jeg vil i første omgang skrive, deretter en test sele, så naiv løsning kode, deretter raffinement.

Jeg har brukt både sammen med Big Upfront Development, alle tre har sine plasser avhengig av forhold som språk, gruppedynamikk og program størrelse / kompleksitet.

I dynamiske språk (særlig ruby), jeg anbefaler TDD, vil det hjelpe deg å fange feil som andre språk ville ha fanget ved kompilering.

I et stort, komplekst system, jo ​​mer design du trenger på forhånd jo bedre blir du. Det virker som når jeg laget for et stort prosjekt, alle områder som jeg hånd-dirigerte og sa "dette bør være ganske rett frem" var en snuble punkt senere i prosjektet.

Hvis du arbeider alene på noe lite i en statisk-skrevet språk, er listen tilnærming rimelig og vil spare deg for en god del tid over TDD (Test vedlikehold er ikke gratis, selv om du skriver testene i første omgang ikke er for dårlig) - Når det ikke er noen tester i det systemet du jobber med, og legger i tester er ikke alltid beundret og du kan selv trekke noen uønsket oppmerksomhet.

Bare fordi testen går, betyr ikke at du er ferdig.

TDD er best preget av Rød - Grønn - Refactor .

Å ha en test gir en (av to) mållinjene. Det er bare den første, minimalt sett med krav. Det virkelige målet er det samme mål som "Pseudo Programmering Process" eller noen design disiplin.

Dessuten er TDD drevet ved testing, men det betyr ikke at drives blindt ved testing. Du kan gjenta ditt teste samme måte som du gjenta koden din. Det er ingen plass for dogmatisk tilslutning til en dum plan her. Dette en en Agile teknikk - det betyr tilpasse det til ditt team og din situasjon.

Designe nok kode for å ha en testbar grensesnitt. Designe nok tester for å være sikker på at grensesnittet vil fungere. Designe noen flere tester og litt mer implementering til du ser behovet for å refactor.

Det virkelige målet er Good Software. TDD kan ikke utelukke "godhet".

En teknikk er ikke en restriktiv mandat. Noen teknikker bør bli sett som en krykke for å hjelpe deg produktet god kode. Hvis jeg var smartere, rikere og bedre utseende, ville jeg ikke trenger TDD. Men siden jeg er så dum som jeg er, trenger jeg en krykke for å hjelpe meg Refactor.

For meg TDD har et ess pseudocoding bare ikke kan konkurrere med - både hjelpe deg med abstrakte og planlegge utviklingen, men når du er ferdig utvikling i TDD land du fortsatt har enheten testene .

AS nyttig en tilnærming som CC2 beskrevet pseudocoding er, det bare ikke kan matche det. TDD er bare halvparten om å designe, det gir også en streng stillas du kan utvikle prosjektet videre fra. Men jeg ser ingen grunn til at du ikke kan pseudokode for å løse problemene TDD sett.

Jeg må ikke utvikle organisk.
Pseudokode er sinnet-morderen.
Det er lite død som bringer prosjektet minne glemsel.
Jeg vil møte min 90-metodikk.
Jeg vil tillate det å passere over meg og gjennom meg.
Og når det har gått forbi Jeg vil snu det indre øyet for å se banen.
Der pseudo har gått der vil bli TDD.
Bare andels tester vil forbli.

(Vennligst ikke flamme meg for det, jeg er bare halvparten seriøs: P)

Mitt team blander begge tilnærminger, og det er en fantastisk måte å utvikle (i hvert fall for oss). Vi trenger enhet tester fordi vi har en stor og kompleks programvare system. Men pseudokode programmeringsprosessen er hendene ned den beste tilnærmingen til software design jeg har kommet over. For å gjøre dem arbeide sammen:

• Vi starter med å skrive våre klasser, og fyll på med fullt kommenmetode stubber, med innganger og utganger.
• Vi bruker par koding og peer gjennomgang som en dialog å avgrense og validere utforming, fortsatt bare til fremgangsmåte stubber.
• På dette punktet har vi nå utviklet både vårt system og har noen testbar kode. Så vi går videre og skrive våre andels tester.
• Vi går tilbake og begynne å fylle i metodene med kommentarer til logikken som må skrives.
• Vi skriver kode; testene passere.

Det fine med det er at etter den tid vi faktisk skrive kode, det meste av arbeidet med gjennomføringen er allerede gjort, fordi så mye av det vi tenker på som gjennomføringen er faktisk kode design. Også den tidlige prosessen erstatter behovet for UML - klasse og metode stubber er like beskrivende, pluss det vil faktisk brukes. Og vi alltid på riktig nivå av abstraksjon.

Tydeligvis prosessen er aldri egentlig ganske så lineær som jeg har beskrevet - noen innfall av implementering kan bety at vi må revidere høyt nivå design. Men generelt, da skriver vi enhet tester design er egentlig ganske stabil (i metoden nivå), så ikke behov for mange test omskriving.