Procesul de programare pseudocod vs Driven Development test

Cu test Driven Development ar trebui să fie în continuare a face unele de planificare la început. Ar trebui să fie mai întâi la un nivel înalt privire la ceea ce încerci să faci. Nu veni cu toate detaliile, dar obține o idee în limba engleză simplu de modul de a rezolva problema.

Apoi începe testarea problema. După ce ați luat testul în loc, începe să-l treacă. În cazul în care nu este ușor de făcut, este posibil să trebuiască să revizuiască planul inițial. Dacă există probleme doar revizuirea. Testul nu este acolo pentru a defini soluția este acolo pentru a vă permite să facă modificări astfel încât să puteți avea o soluție mai bună asigurând în același timp stabilitatea.

Aș spune că cel mai bun pariu este de a utiliza TDD. Cheia este de a realiza că TDD nu înseamnă „săriți de planificare“. TDD înseamnă a face un pic de planificare pentru a începe bine, și ajustați în funcție de necesități. Nici măcar nu poate fi necesar să se adapteze.

În general, mi se pare pseudocod doar devine cu adevărat relevant atunci când codul necesar pentru a rezolva problema este mult mai complicată decât codul necesar pentru a testa soluția. În cazul în care acest lucru nu este cazul, eu nu alerga în dificultățile pe care le descrie ca cel mai simplu lucru care ar putea lucra, eventual, este, de obicei, o soluție acceptabilă pentru suma de timp în valoare de cheltuieli pe problema.

În cazul în care , pe de altă parte, problema este complicată, trebuie să se gândească cum să - l abordare înainte de a putea scrie chiar și o soluție de naiv inițială - eu încă mai trebuie să -și planifice înainte de codul I; Prin urmare, folosesc o combinație a celor două abordări: o descriere în limba engleză a ceea ce voi scrie la început, apoi un ham de test, cod soluție apoi naiv, apoi rafinament.

Am folosit atât împreună cu Big Upfront de dezvoltare, toate cele trei au locurile lor în funcție de aspecte, cum ar fi limba, dinamica echipei și dimensiunea programului / complexitate.

În limbi dinamice (mai ales Ruby), am foarte recomanda TDD, aceasta va ajuta să prinde erori care alte limbi ar fi prins la momentul compilarii.

Într-un sistem mare, complex, cu atât mai mult de design vă face mai direct în cu atât mai bine va fi. Se pare că atunci când am proiectat pentru un proiect de mari dimensiuni, fiecare zona pe care am mână-vălurită și a spus „acest lucru ar trebui să fie destul de drept înainte“, a fost un punct de poticnire mai târziu în proiect.

Dacă lucrați singur pe ceva mic într-un limbaj tastat-static, abordarea listă este rezonabil și vă va salva o afacere bună de timp de peste TDD (de întreținere de testare nu este liber, deși scris testele, în primul rând, nu este prea rău) - Atunci când nu există nici un test în sistemul pe care lucrați, adăugând în teste nu este întotdeauna admirat si s-ar putea atrage chiar unele atenție nedorită.

Doar pentru că trece testul, nu înseamnă că ai terminat.

TDD este cel mai bine caracterizat prin Roșu - Verde - Refactor .

Având un test oferă una (de două) linii de obiectiv. Este doar primul set, minim de cerințe. Scopul real este același obiectiv ca „proces de programare pseudocod“ sau orice disciplină de proiectare.

De asemenea, TDD este condus de testare, dar asta nu înseamnă condus orbește prin testare. Puteți itera testarea dvs. în același mod în care itera codul. Nu există nici un loc pentru aderarea dogmatică la un plan mut aici. Aceasta o o tehnica Agile - ceea ce înseamnă adapta la echipa și circumstanțele.

Proiectați suficient de cod pentru a avea o interfață testabile. Proiectarea suficient de teste pentru a fi sigur că interfața va funcționa. Proiectarea unele mai multe teste și ceva mai mult de punere în aplicare până când vedeți nevoia de a refactor.

Scopul real este bun software. TDD nu se poate exclude „facerea de bine“.

O tehnică nu este un mandat restrictiv. O tehnici ar trebui să fie privit ca o carja pentru a vă ajuta la codul de produs bun. Dacă aș fi fost mai inteligent, mai bogată și cu aspect mai bine, n-aș avea nevoie de TDD. Dar din moment ce eu sunt la fel de prost ca mine, am nevoie de o carja să mă ajute Refactor.

Pentru mine TDD are un pseudocoding as pur si simplu nu poate concura cu - atât te ajuta abstracte și planul de dezvoltare, dar odată ce ați terminat de dezvoltare în țara TDD aveți în continuare teste unitare .

AS utilă o abordare așa cum este descris CC2 pseudocoding este, pur și simplu nu se poate potrivi asta. TDD este doar jumătate cu privire la proiectarea, este, de asemenea, oferind o schela riguros vă poate evolua proiectul înainte de. Cu toate acestea nu văd nici un motiv pentru care nu se poate pseudocod pentru a rezolva seturi probleme TDD.

Nu trebuie să se dezvolte organic.
Pseudocod este mintea-criminal.
Este puțin moarte care aduce uitarea de memorie de proiect.
Voi confrunta cu metodologia mea 90.
O voi lăsa să treacă peste mine și prin mine.
Și când a trecut , îmi va întoarce ochiul interior pentru a vedea calea.
În cazul în care pseudocod a intrat acolo va fi TDD.
Numai titluri de teste vor rămâne.

(Vă rugăm să nu mă flacără pentru că, eu sunt doar pe jumătate serios: P)

Echipa mea amesteca ambele abordări și este un mod minunat de a dezvolta (cel puțin pentru noi). Avem nevoie de teste unitare pentru că avem un sistem software mare și complex. Dar pseudocod de programare Procesul este mâinile în jos cea mai bună abordare a software de proiectare am venit peste. Pentru a le face să lucreze împreună:

• Începem prin scrierea clasele noastre, și completați cu cioturi metoda complet comentat, cu intrări și ieșiri.
• Noi folosim pereche de codificare și peer review ca un dialog pentru a rafina și valida proiectarea, încă doar cu stub metoda.
• În acest moment ne-am proiectat acum atât sistemul nostru și să aibă un cod testabile. Așa că vom merge mai departe și scrie testele noastre unitare.
• Ne întoarcem și să înceapă completarea metodelor cu comentarii pentru logica care trebuie să fie scris.
• Scriem cod; testele trec.

Frumusețea este faptul că în momentul de fapt am scrie cod, cele mai multe dintre lucrările de punere în aplicare este deja făcut, pentru că atât de mult din ceea ce ne gândim ca implementare este de fapt un design cod. De asemenea, procesul de timpuriu inlocuieste necesitatea UML - clasa si metoda cioturi sunt la fel de descriptive, plus acesta va fi folosit efectiv. Și noi rămâne întotdeauna la nivelul corespunzător de abstractizare.

Evident, procesul este într-adevăr nu la fel de liniar așa cum am descris - unele capriciu de punere în aplicare poate însemna că trebuie să revizuiască proiectarea la nivel înalt. Dar, în general, de timp am scrie unitate testează design-ul este într-adevăr destul de stabil (la nivelul metodei), astfel încât nu este nevoie de o mulțime de rescriere de testare.