Kent Beck - Programare extremă. Dezvoltare prin teste

Gen:

Serie:
Restrictii de varsta: +
Limba:
Limba originală:
Traducător:
Editor:
Orașul publicării: St.Petersburg
Anul publicării:
ISBN: 978-5-496-02570-6 Marimea: 382 KB.

Titularii de drept!

Fragmentul prezentat al lucrării este postat în coordonare cu distribuitorul conținutului juridic LLC "Litri" (nu mai mult de 20% din textul sursă). Dacă credeți că plasarea materialului încalcă drepturile cuiva, atunci.

Cititorii!

Plătite, dar nu știu ce să facă în continuare?

Atenţie! Descărcați un extras permis de lege și deținătorul dreptului (nu mai mult de 20% din text).
După citire, vi se va cere să mergeți la site-ul titularului drept și să achiziționați versiunea completă a lucrării.

Descrierea cărții

Întoarcerea faimosului bestseller. Cod elegant, flexibil și clar, care este ușor de modificat, care funcționează corect și care nu ridică creatorii lor de surprize neplăcute. Este cu adevărat posibil? Pentru a atinge un obiectiv, încercați să testați programul chiar înainte de a fi scris. Este o idee paradoxală care se bazează pe tehnica TDD (dezvoltarea bazată pe test - dezvoltarea bazată pe testarea). Prostii? Nu vă grăbiți să faceți concluzii precoce. Având în vedere utilizarea TDD cu privire la exemplul dezvoltării unui cod de program real, autorul demonstrează simplitatea și puterea acestei tehnici. Cartea conține două proiecte de program, implementate integral și complet utilizând TDD. Pentru examinarea exemplelor, un catalog extins de tehnici în stil TDD, precum și modele și refactoringuri legate de TDD. Cartea va fi utilă pentru orice programator care dorește să îmbunătățească performanța muncii dvs. și să se bucure de programare.

Ultima impresie a cărții

Sharedrharpened:
16-12-2018, 02:17

Înainte de a citi această carte, am încercat să scriu teste pe articolele pe care le-am citit, dar numai cu ea a început să se facă bine.

Am citit de două ori. Prima dată citește.

Nu a înțeles nimic. A doua oară am scris codul în cursul citirii cărții și apoi mi-a venit la mine ce să fac și cel mai important - am simțit pasul meu de pas la care pot schimba codul și, în același timp, nu aș fi făcut-o își pierde controlul. Am fost mulțumit de cel de-al doilea capitol în care împreună cu autorul mi-a scris sistemul de testare modulară pe Python, sentimentul a fost ca și cum ați face o operațiune pe creierul meu (de fapt, această comparație a fost autorul însuși și autorul însuși) - O mișcare fără griji în sine și nu funcționează, trebuie să mutați pași foarte mici. Am citit selectiv al treilea capitol, poate într-o zi am citit.

Turn

⬇ Alte comentarii

Această carte este despre programarea extremă. Programarea extremă, deseori denotată de abrevierea "XP" - aceasta este o metodă simplificată de organizare a producției pentru echipele de dezvoltatori mici și mijlocii produs software. În condiții de cerințe neclare sau rapid în schimbare. Această carte este concepută pentru a vă ajuta să determinați dacă utilizarea XP este justificată în situația dvs. ...

Despre seria XP

Programare extremă (programare extremă), deseori denotată de abrevierea XP, este disciplina de dezvoltare software. și să facă afaceri în domeniul creării de software, care concentrează eforturile ambelor părți (programatori și oameni de afaceri) în scopuri comune, pe deplin realizabile. Echipele care utilizează XP produc software de înaltă calitate cu o viteză foarte mare. Tehnicile care fac parte din disciplina a XP descrise în această carte sunt alese datorită faptului că se bazează pe creativitatea umană și pe adoptarea faptului că o persoană este o creatură instabilă și predispusă la erori.

XP este adesea reprezentat ca un set de tehnici, dar HP în sine nu este linia de sosire. Nu trebuie să fiți mai bine și mai bine practicarea și dezvoltarea XP pentru a obține o stea de aur mult așteptată la sfârșitul acestui proces. Dimpotrivă, XP este o linie de pornire. XR ridică întrebarea: "Cât de minimal pot fi eforturile noastre pentru a continua să producem software de înaltă calitate?"

Începutul răspunsului la întrebarea sună astfel: dacă vrem să dezvoltăm programe de înaltă calitate fără tulburări și confuzie, trebuie să fim finalizați în întregime și pe deplin în echipa noastră mai multe tehnici pe care le vom folosi pe deplin. Dacă folosim aceste tehnici la jumătate, problemele vor rămâne și vor decide, va fi necesar să se procedeze la utilizarea tehnicilor la maxim. Dacă ne limităm la semi-dimensiuni, în timp, ne confundăm atât de mult încât nu putem înțelege că este principalul lucru care este creat de munca programatorilor, apare pentru programare.

Am spus "începutul răspunsului la", deoarece continuarea nu există cu adevărat. Oamenii care au creat și au introdus XP se gândesc, de asemenea, la decizia acestei probleme. A încercat să folosească XP, au pășit peste prag și au vizitat nechimbul. Revenind, au spus povestea lor. Gândurile declarate de ei sunt indicii plasați de-a lungul drumului: "Dragonii locuiesc aici", se deschide 15 km vedere bună"," Acest complot este periculos în timpul ploii. "

Îmi cer scuze, dar e timpul să programez.

Prefaţă

Programare extremă (

programare extremă

XP) definește codarea ca activități cheie și fundamentale atunci când lucrați la un proiect de software. Este posibil ca acesta să fie greșit!

Cred că merită să vă amintiți propria mea experiență în dezvoltarea software-ului. Lucrez într-un mediu în care produsul care se dezvoltă este în mod constant în conditii de lucruȘi, în același timp, schimbările sunt introduse în mod constant în ea. Termenele limită pentru eliberarea următoarei versiuni funcționale sunt comprimate monstruos și, în același timp, există un risc tehnic imens față de toate acestea. Într-un mediu similar, abilitatea de a repara asociatul dvs. este o artă fără de care nu este supraviețuită. Partajarea informațiilor atât în \u200b\u200binteriorul unei echipe, cât și între mai multe comenzi, care sunt adesea separate din punct de vedere geografic, se efectuează utilizând codul. Citiți codul pentru a înțelege dispozitivul de interfețe software noi sau modificate de sistem. Ciclu de viață și comportamentul obiecte complexe Definit folosind cazuri de testare, adică din nou cu codurile. Mesajele despre problemele emergente sunt însoțite de cazuri de testare care arată problema, codul este folosit din nou. În cele din urmă, suntem angajați în mod constant în îmbunătățirea codului existent, făcându-l mai productiv, mai flexibil, mai ușor de înțeles. Evident, în astfel de condiții, dezvoltarea unui produs software este aproape în întregime bazată pe codificare, dar în același timp putem completa cu succes proiectele de timp, deci această abordare destul de viabil.

Nu ar trebui să concluzionăm că tot ceea ce aveți nevoie pentru implementarea cu succes a Proiectului Program este profitarea programului Fierce. Dezvoltarea software-ului este foarte dificilă, dar pentru a dezvolta software de înaltă calitate și, în același timp, a terminat munca la timp - și mai dificilă. Pentru ca abordarea descrisă de mine, este necesar să se aplice în mod consecvent reguli și tehnici suplimentare importante. Din aceasta, Kent Beck (Kent Beck) începe cartea sa pozitivă pe XP.

Am colaborat cu Kent și am folosit episoadele descrise în cadrul XP atunci când lucrează la un proiect mic, dar nesolicitat numit Junit

Introducere

Această carte despre programarea extremă (

programare extremă

Xp). Programarea extremă este o metodă simplificată de organizare a producției pentru echipele mici și mijlocii de specialiști implicați în dezvoltarea unui produs software în condiții de cerințe neclare sau rapid în schimbare. Această carte este concepută pentru a ajuta la determinarea dacă utilizarea XP este justificată în situația dvs.

Pentru multe XP arată ca un set de lucruri destul de acceptabile și justificate din punctul de vedere al metodelor de organizare a forței de muncă. Atunci de ce programarea în conformitate cu tehnicile XP se numește extremă? Faptul este că XP aduce utilizarea multor principii de programare general acceptate și utilizate pe scară largă la niveluri extreme.

Dacă revizuirea codului este bună, înseamnă că vom revizui codul în mod constant (în perechi);

Testarea Eans este bună, fiecare participant la proiect va testa Codul programului în mod constant (modulele de testare), chiar și clienții ( testarea funcțională);

Designul Ersee este bun, înseamnă că designul trebuie făcut parte din activitatea zilnică a fiecărui participant la proiect (reciclarea codului);

Programare extremă

Dedicat tatălui meu și îi mulțumesc lui Cindy (Cindee Andres), soția și partenerul meu, pentru că cer să nu o acord și să-l amintesc. Datorită Bethany, Lincoln (Lincoln), Forrest (Forrest) și pentru că nu mă distrage și mi-a oferit să scriu.

Despre seria XP

Programare extremă (programare extremă), deseori denotată printr-o abreviere a XP, este disciplina dezvoltării și afacerilor de software în domeniul creării de produse software, care să conceapă eforturile ambelor părți (programatori și oameni de afaceri) în scopuri comune, pe deplin realizabile. Echipele care utilizează XP produc software de înaltă calitate cu o viteză foarte mare. Tehnicile care fac parte din disciplina a XP descrise în această carte sunt alese datorită faptului că se bazează pe creativitatea umană și pe adoptarea faptului că o persoană este o creatură instabilă și predispusă la erori.

Am spus "începutul răspunsului la", deoarece continuarea nu există cu adevărat. Oamenii care au creat și au introdus XP se gândesc, de asemenea, la decizia acestei probleme. A încercat să folosească XP, au pășit peste prag și au vizitat nechimbul. Revenind, au spus povestea lor. Gândurile declarate de ei sunt indicate de-a lungul drumului: "Dragonii locuiesc aici", "15 km deschide o priveliște bună", acest site este periculos în timpul ploii ".

Îmi cer scuze, dar e timpul să programez.

Kent Beck, seria consultantului

Prefaţă

Programare extremă ( programare extremă, XP) definește codificarea ca activități cheie și fundamentale atunci când lucrați la un proiect de program. Este posibil ca acesta să fie greșit!

Cred că merită să vă amintiți propria mea experiență în dezvoltarea software-ului. Lucrez într-un mediu în care produsul care este dezvoltat este constant într-o stare de lucru, iar schimbările sunt introduse în mod constant în ea. Termenele limită pentru eliberarea următoarei versiuni funcționale sunt comprimate monstruos și, în același timp, există un risc tehnic imens față de toate acestea. Într-un mediu similar, abilitatea de a repara asociatul dvs. este o artă fără de care nu este supraviețuită. Partajarea informațiilor atât în \u200b\u200binteriorul unei echipe, cât și între mai multe comenzi, care sunt adesea separate din punct de vedere geografic, se efectuează utilizând codul. Citiți codul pentru a înțelege dispozitivul de interfețe software noi sau modificate de sistem. Ciclul de viață și comportamentul obiectelor complexe sunt determinate utilizând cazuri de testare, adică din nou cu codurile. Mesajele despre problemele emergente sunt însoțite de cazuri de testare care arată problema, codul este folosit din nou. În cele din urmă, suntem angajați în mod constant în îmbunătățirea codului existent, făcându-l mai productiv, mai flexibil, mai ușor de înțeles. Evident, în astfel de condiții, dezvoltarea unui produs software este aproape în întregime bazată pe codificare, dar, în același timp, putem completa cu succes proiectele de timp, astfel, această abordare este destul de viabilă.

Kent a fost printre acei lideri ai Tektronix, care și-a dat seama de potențialul enorm stabilit în metodologia de programare din perechi conexe atunci când dezvoltă aplicații complexe de inginerie în mediul SmallTalk. Împreună cu Bard Cunningham (Ward Cunningham), Kent a devenit o dezvoltare inspirată a metodelor de programare pentru eșantioane (se numește și programare folosind modele - programarea modelelor.care mi-a influențat foarte mult propria carieră. În cadrul XP, abordarea la dezvoltarea software-ului, care combină metodele utilizate de numeroasele dezvoltatori de lucru cu succes care au studiat multe literaturi cu privire la organizarea programatilor de muncă și au încercat în practică multe metode și proceduri pentru dezvoltarea unui produs software . Ca și programa de probă, XP formează un set de tehnici cele mai eficiente, cum ar fi testarea modulelor software, programarea de vapori și reciclarea codului. Ca parte a XP, aceste tehnici sunt combinate în așa fel încât să se completeze și să se controleze adesea reciproc. Scopul principal al acestei cărți este de a vorbi despre interacțiunea și partajarea diferitelor tehnici. În toate tehnicile de programare, un obiectiv este de a crea un produs software cu o funcție dată într-o anumită perioadă. Oti-ul propus este un foarte reușit doar în procesul de software de timp nu este XP în forma purăCu toate acestea, există o mulțime de comune între aceste două abordări.

Am colaborat cu Kent și am folosit episoadele descrise în cadrul XP atunci când lucrează la un proiect mic, dar necorespunzător numit Junit. Opiniile și abordările sale pentru dezvoltarea programelor mi-au format întotdeauna să mă gândesc la modul în care am lucrat personal la un proiect de program. Fără îndoială, XP prezintă problema multor abordări tradiționale utilizate în industria de programare. După ce ați citit această carte, puteți decide pe cont propriu, trebuie să aplicați XP în munca dvs. sau nu.

Programare extremă

Despre seria XP

Am spus "începutul răspunsului la", deoarece continuarea nu există cu adevărat. Oamenii care au creat și au introdus XP se gândesc, de asemenea, la decizia acestei probleme. A încercat să folosească XP, au pășit peste prag și au vizitat nechimbul. Revenind, au spus povestea lor. Gândurile declarate de ei sunt indicate de-a lungul drumului: "Dragonii locuiesc aici", "15 km deschide o priveliște bună", acest site este periculos în timpul ploii ".

Îmi cer scuze, dar e timpul să programez.

Kent Beck, seria consultantului

Prefaţă

Programare extremă ( programare extremă, XP) definește codificarea ca activități cheie și fundamentale atunci când lucrați la un proiect de program. Este posibil ca acesta să fie greșit!

Kent a fost printre acei lideri ai Tektronix, care și-a dat seama de potențialul enorm stabilit în metodologia de programare din perechi conexe atunci când dezvoltă aplicații complexe de inginerie în mediul SmallTalk. Împreună cu Bard Cunningham (Ward Cunningham), Kent a devenit o dezvoltare inspirată a metodelor de programare pentru eșantioane (se numește și programare folosind modele - programarea modelelor.care mi-a influențat foarte mult propria carieră. În cadrul XP, abordarea la dezvoltarea software-ului, care combină metodele utilizate de numeroasele dezvoltatori de lucru cu succes care au studiat multe literaturi cu privire la organizarea programatilor de muncă și au încercat în practică multe metode și proceduri pentru dezvoltarea unui produs software . Ca și programa de probă, XP formează un set de tehnici cele mai eficiente, cum ar fi testarea modulelor software, programarea de vapori și reciclarea codului. Ca parte a XP, aceste tehnici sunt combinate în așa fel încât să se completeze și să se controleze adesea reciproc. Scopul principal al acestei cărți este de a vorbi despre interacțiunea și partajarea diferitelor tehnici. În toate tehnicile de programare, un obiectiv este de a crea un produs software cu o funcție dată într-o anumită perioadă. Procesul de succes al OTIS de succes la timp nu este XP în forma sa pură, dar există o mulțime de comune între aceste două abordări.

Erich Gamma (Erich Gamma)

Introducere

Această carte despre programarea extremă ( programare extremă, Xp). Programarea extremă este o metodă simplificată de organizare a producției pentru echipele mici și mijlocii de specialiști implicați în dezvoltarea unui produs software în condiții de cerințe neclare sau rapid în schimbare. Această carte este concepută pentru a ajuta la determinarea dacă utilizarea XP este justificată în situația dvs.

Dacă revizuirea codului este bună, înseamnă că vom revizui codul în mod constant (în perechi);

Testarea Eans este bună, fiecare participant la proiect va testa Codul programului în mod constant (modulele de testare), chiar și clienții (testarea funcțională);

Designul Ersee este bun, înseamnă că designul trebuie făcut parte din activitatea zilnică a fiecărui participant la proiect (reciclarea codului);

Simplitatea Esley este bună, înseamnă că trebuie să menținem cel mai simplu design din sistem, oferind nivelul actual de funcționalitate (cel mai simplu lucru care va funcționa cel mai probabil); Dacă arhitectura este importantă, înseamnă că fiecare dintre participanții la proiect va lucra continuu la definirea și revizuirea arhitecturii (metaforă);

ESLEY Integrare Testarea este importantă, înseamnă că este necesar să se colecteze și să se testeze sistemul de mai multe ori pe zi (integrare continuă);

Esley Iterații mici sunt bune, este necesar să se facă iterații foarte, foarte mici - secunde, minute, poate ore, dar nu săptămâni și luni, și în nici un fel de ani (joc în planificare).

Când am decis mai întâi să formulez esența lui XP pentru mine, mi-am imaginat un set de mânere pe panoul de control. Fiecare mâner corespundea unei anumite metodologii despre care dintre el experienta personala Știam că era destul de eficient. Fiecare mâner a permis să utilizeze această tehnică sau această tehnică într-o anumită măsură: de la 1 la 10. Am încercat să instalez toate mânerele la poziția maximă maximă (10) și am fost surprins că setul complet de metode considerate de mine rămâne stabil, previzibil și flexibil.

XP formează două seturi de promisiuni:

Programatorii XP promite că fiecare dintre ele va lucra la soluționarea unor sarcini cu adevărat importante în fiecare zi lucrătoare. Fiecare dintre ele nu va fi niciodată într-o cantitate singură. Fiecare dintre ele va fi capabil să facă totul în depinde de a face ca sistemul să fie dezvoltat cu succes. Fiecare dintre ele va putea lua o decizie tocmai în zona în care este competentă și, dacă nu este competentă într-o anumită regiune, aceasta nu va participa la luarea deciziilor.

Clienții și managerii HR promite că vor primi revenirea maximă posibilă din fiecare săptămână de lucru la proiect. La fiecare câteva săptămâni vor putea să vadă progrese în atingerea obiectivelor lor. Ei vor avea ocazia să schimbe direcția de dezvoltare a proiectului chiar în mijlocul dezvoltării, fără teama de costuri extraordinare suplimentare.

Dacă vorbiți scurt, XP promite să reducă riscul asociat riscului, să îmbunătățească reacția la schimbarea afacerilor, să îmbunătățească performanța proiectului și să facă procesul de dezvoltare a software-ului este mai plăcut - și toate acestea în același timp. Nu glumesc, râd suficient. Doar citesc această carte, iar tu poți verifica dacă sunt nebun.

Această carte

Această carte poveste despre lucruri legate de metoda XP, rădăcinile, filozofia, diferite tipuri de povestiri și mituri. Cartea este concepută pentru a vă ajuta să luați o decizie ponderată dacă este necesar să utilizați XP în propriul proiect. Dacă, după ce ați citit această carte, ați decis să nu utilizați XP Când lucrați la proiectul dvs., voi lua în considerare obiectivul principal realizat în același mod ca și cum, după ce ați citit această carte, veți lua decizia că XP este ceea ce aveți nevoie . Al doilea scop al cărții este de a ajuta pe aceia dintre voi care utilizează deja XP. După citirea cărții, astfel de cititori vor putea înțelege mai bine această tehnică.

Această carte nu conține instrucțiuni exacte cu privire la modul în care trebuie efectuată procesul de programare extremă. Nu veți vedea multe exemple, algoritmi sau povestiri de programare în ea. Pentru a obține totul, puteți căuta pe Internet, discutați cu unii dintre participanții la proiect, așteptați apariția cărților dedicate acestui lucru sau cum să creați un astfel de material.

Soarta ulterioară descrisă de mine Disciplina Dezvoltării Software XP este în mâinile unui grup de oameni (poate că sunteți unul dintre ei), care sunt nemulțumiți de existența acest moment Metode tradiționale de organizare a muncii programatorilor. Ai nevoie de B. cea mai buna cale Dezvoltarea de software, doriți să stabiliți relații mai productive și mai prietenoase cu clienții dvs., doriți să faceți lucrul sub programatorii dvs. de conducere mai fericiți, mai loiali și mai productivi. Pe scurt, doriți să obțineți un avantaj semnificativ și nu vă este frică să profitați de idei noi pentru a obține acest avantaj. Cu toate acestea, înainte de risc, doriți să vă asigurați că nu sunteți cel puțin un nebun complet.

XP vă prescrie să faceți munca destul de diferită de faptul că sunteți obișnuiți cu acest lucru. În unele cazuri, recomandările XP contrazic total standardele general acceptate. Pe acest moment Cred că numai cei care au motive semnificative pentru schimbarea ordinii existente de lucruri vor putea să utilizeze XP. Cu toate acestea, dacă există astfel de motive, puteți începe să utilizați XP chiar acum. Am scris această carte, astfel încât să puteți afla despre aceste motive mai mult.

Ce este XP?

Ce este XP? XP este o modalitate simplificată, eficientă, flexibilă, previzibilă, bazată pe științifică și foarte plăcută de a dezvolta software-ul care oferă nivel scăzut risc. Din alte metode, XP diferă în următoarele caracteristici.

Datorită utilizării ciclurilor extrem de scurte, dezvoltarea XP oferă feedback rapid, real și constant funcționând.

În cadrul XP, planificarea creșterii, ca rezultat, planul general al proiectului apare destul de repede, dar se înțelege că acest plan evoluează pe tot parcursul vieții proiectului.

În cadrul XP, se utilizează un program flexibil de realizare a uneia sau al unei alte funcționalități, îmbunătățind astfel reacția la schimbarea naturii afacerii și schimbarea cerințelor clientului.

XP se bazează pe testele automate dezvoltate atât de programatori, cât și de clienți. Datorită acestor teste, este posibil să se monitorizeze procesul de dezvoltare, să asigure o evoluție corectă a sistemului și fără întârziere pentru a detecta defectele existente în sistem.

XP se bazează pe un schimb oral de informații, teste și cod sursă. Cele trei instrumente sunt utilizate pentru a face schimb de informații despre structura sistemului și comportamentul acestuia.

XP se bazează pe procesul de evoluție, care continuă atât timp cât există sistemul însuși.

XP se bazează pe interacțiunea strânsă a programatilor care au cele mai comune abilități și capabilități.

XP se bazează pe metode care satisfac atât instinctele pe termen scurt ale programatilor individuali, cât și interesele pe termen lung ale întregului proiect în ansamblu.

XP este o disciplină de dezvoltare a software-ului. Aceasta este disciplina deoarece, în cadrul XP, există anumite lucruri pe care trebuie să le faceți dacă intenționați să utilizați XP. Nu trebuie să alegeți, este necesar sau să nu scrieți teste, deoarece dacă nu faceți acest lucru, programarea pe care o faceți, nu puteți fi numită Extreme: sfârșitul discuției.

Tehnica XP este concepută pentru a lucra la proiecte care pot lucra de la doi la zece programatori care nu sunt fixați în cadrul rigid al unui mediu informatic existent și în care toată lucrările necesare de testare pot fi efectuate în decurs de o zi.

XP sperie sau enervant unii oameni care se confruntă cu această tehnică pentru prima dată. În același timp, nici o idee care stau la baza XP nu este nouă. Într-un sens, metoda XP este conservatoare - toate tehnicile utilizate în cadrul său sunt testate până la decenii (în ceea ce privește strategia de implementare) și chiar de secole (în ceea ce privește strategia de management).

În inovațiile din XP sunt următoarele caracteristici:

Toate aceste tehnici de lungă durată sunt asamblate sub un singur acoperiș;

Intensitatea cu care aceste tehnici sunt introduse în munca de zi cu zi este adusă la extreme;

Tehnicile utilizate sunt susținute de una dintre celelalte în cel mai mare grad posibil.

Adecvare

În lucrările lor Poporul pădurii (popoarele de pădure) și muntele (popoarele de munte) Antropologul Colin Turnbull (Colin Turnbull) descrie două societăți complet diferite unul de celălalt. În munții necesari pentru viață, lipsesc resursele, iar oamenii sunt mereu pe punctul de a fi foame. Cultura care a apărut în astfel de condiții pare teribilă. Mamele își aruncă copiii pentru a se supraviețui. Impregnarea poate provoca vătămări. Cruzimea, atrocitățile și trădarea sunt obișnuite și de zi cu zi.

Spre deosebire de munți, pădurea este saturată de resurse. Pentru a asigura aportul pentru o zi întreagă, o persoană este suficientă pentru a petrece aproximativ o jumătate de oră. Cultura forestieră este o reflectare a culturii miniere. Adulții participă la cultivarea și educația copiilor obișnuiți care cresc în dragoste și îngrijire până când devin suficient capabili să aibă grijă de ei înșiși. Dacă o persoană ucide o altă persoană (uciderea deliberată a acestor oameni nu este familiară), el este expulzat din societate. Cu toate acestea, în același timp, exilul ar trebui să fie îndepărtat în pădure și să petreacă câteva luni acolo, și chiar și atunci unii membri ai tribului îi aduc hrană și daruri.

XP este o încercare de a răspunde la întrebarea: Cum ați programa personal dacă ați avut timp suficient? De fapt, nu aveți prea mult timp, deoarece în programul de programare este o afacere. În orice afacere câștigă cel care face munca mai rapidă. Cu toate acestea, dacă aveți timp, probabil că veți acorda atenție dezvoltării testelor; Probabil că ați redona arhitectura sistemului în cazul în care ar fi necesar să se concluzioneze că este necesar; Veți comunica cu siguranță cu tovarășii programatori, precum și cu clientul.

Un sentiment similar de suficiență arată mai uman, spre deosebire de situațiile în care programatorii din ultimele forțe încearcă să rămână la un anumit cadru temporar, să bată din program, nu au timp să efectueze o cantitate mare de lucru extrem de importantă numai în ordine pentru a trece proiectul la timp. Grăbește-te împiedică programatorii să-și arate pe deplin talentele și să se bucure de muncă. Cu toate acestea, începând să exploreze XP, trebuie să înțelegeți că sentimentul de suficiență este, de asemenea, o afacere bună. Sentimentul de suficiență devine o sursă de eficiență în același mod ca un sentiment de lipsă dă naștere unor defecțiuni, duce la apariția defectelor și o reducere a calității și, în cele din urmă, o scădere a productivității muncii.

Carte de plată

Cartea este scrisă ca și cum ați fi implicată și în crearea unei noi discipline de dezvoltare software. Începi cu studiul ideilor noastre de bază despre dezvoltarea software-ului. După aceea, creăm de fapt o nouă disciplină. Apoi studiem consecințele a ceea ce am creat - cum poate fi implementat și utilizat în practică atunci când nu ar trebui să fie utilizat și ce oportunități se deschide afacerii.

Cartea este împărțită în trei părți.

Problemă: În capitole, începând cu Riscul: Principala problemă Și finisaje Înapoi la originileProblema se determină că programarea extremă încearcă să rezolve, iar criteriile sunt stabilite prin care poate fi estimată calitatea soluției. În această parte obțineți o idee generală despre metoda de programare extremă.

Decizie: În capitole, începând cu Revizuire scurtă Și finisaje Strategia de testare, Ideile abstracte prezentate în prima parte a cărții sunt convertite într-un set de tehnici de disciplină specifice. Acest capitol nu conține informații despre exact cum puteți aplica tehnicile descrise în practică. În schimb, vorbim despre forma generală a fiecărei tehnici. Susținerea despre fiecare tehnică, îl asociem cu probleme și principii discutate în prima parte a cărții.

Realizarea XP.: În capitole, începând cu Introducere XP. Și finisaje XP în muncăSunt discutate numeroasele întrebări legate de introducerea XP-ului - cum să introduceți XP, care ar trebui să fie așteptat de la diferite persoane care participă la proiectul HP, care ideea de XP se dezvoltă în oamenii din lumea afacerilor.

Mulțumiri

Apel la cititorii de la prima persoană nu pentru că cartea prezintă propriile mele idei și pentru că vă spun despre propria mea percepție a acestor idei. Majoritatea tehnicilor utilizate în cadrul XP sunt vechi ca toate programarea.

Ward Cunningham (Ward Cunningham) este sursa mea principală de la care ți-am strigat în materialul cărții. Într-un fel sau altul, am petrecut ultimii cincisprezece ani, încercând doar să-i explic celorlalți ce Vard a fost practic implicat în aproape o lungă perioadă de timp. Vă mulțumim, de asemenea, la Jeffries Ron pentru faptul că a încercat, de asemenea, și apoi sa îmbunătățit semnificativ. Datorită lui Martin Fower (Martin Fowler) pentru a explica toate acestea printr-o limbă simplă moale și fără întreruperi nervoase. Datorită lui Erich Gamma (Erich Gamma) pentru conversații lungi, combinate cu contemplarea lebedelor în limbă, precum și pentru că nu mă permite să-l las cu gânduri rele în capul meu. Și, bineînțeles, nimic nu s-ar întâmpla în viața mea dacă n-aș avea un exemplu de imitație, ca și tatăl meu, Doug Beck, care și-a păstrat abilitățile de programare de mai mulți ani.

Datorită echipei C3 din compania Chrysler pentru că mi-a însoțit în sondajele mele. Și, de asemenea, mulțumită deosebită managerilor noștri de la Sue o furie (Ron Savage) pentru faptul că au avut suficientă curaj pentru a ne încerca.

Mulțumită lui Daedalos Consulting pentru a scrie această carte.

Recompenirea campionatului pentru vizionarea materialului intră în mâinile lui Paul Chisholm (Paul Chisholm) pentru comentariile sale abundente, capace, scrupuloase și adesea enervante. Fără ajutorul lui această carte Nu aș fi fost atât de popular.

Chiar am mare plăcere să comunice cu toți cei care au efectuat previzualizare ce am scris.

Lucrarea lor a devenit un ajutor imens pentru mine. Nu pot găsi cuvintele de recunoștință pentru faptul că au avut suficientă răbdare să citească toată această proză, pentru că mulți dintre ei subliniate într-o limbă străină.

Mulțumesc (într-o ordine aleatorie în care am primit comentarii de la ei) Greg Hutchinson, Massimo Arnoldi, Dave Cleal, aceleași Schuster, Don Wells, Joshua Keievsky, Torsten Dittmar (Thorsten Dittmar), Moritz Beker (Daniel Gubler), Christofe Henric ( Christoph Henrici), Thomas Zangu (Dierk Koenig), Miroslav Novaka (Mroslav Novak), Rodney Rodney Rodney, Frank Westphal, Paul Trunz, Steve Hayes (Steve Hayes), Kevin Bradtke, Janny de Guzman (Jeanine de Guzman), la Kubit ( Tom Kubit), Falkmann, Hasko Heinec (Peter Mell), Rob MC (Rob Mell), McBreen, Tomas Ernstu (Thomas Ernst), Guido Hchelle (Guido Hachler), Dieter Holz, Martin Knecht, Dirka Krampe ( Dierk Krampe), Patrick Lisser (Patrick Lisser), Elisabeth Maier, Thomas Mancini (Thomas Mancini), Aleksio Moro (Alexio Moreno), Rolf Pfenninger (Rolf Pfenning) și Matthias Ressel).

De la publicare

Comentariile, sugestiile, trimiteți întrebări la e-mail [E-mail protejat] (Editura Peter, editorial de calculator).

Vom fi bucuroși să vă cunoaștem părerea!

Toate textele sursă din cartea pe care o puteți găsi la http://www.piter.com/download..

Pe site-ul web al editurii http://www.piter.com veți găsi informații detaliate despre cărțile noastre.

Problemă

În această parte a cărții, scena este pregătită pe care programarea extremă ar trebui să fie ulterioară. Descrie diferitele aspecte ale problemei care trebuie rezolvate prin formarea unei noi discipline de dezvoltare software.

Această secțiune discută ipotezele de bază pe care trebuie să le luăm în considerare prin selectarea tehnicilor de dezvoltare a software-ului, metafora de management al mașinilor, patru valori, principiile formate pe baza acestor valori, precum și activitățile care trebuie să fie structurate în Cadrul unei noi discipline de dezvoltare a software-ului.

Riscul: Principala problemă

Disciplinele existente ale dezvoltării de software nu sunt declanșate și nu dau efectul economic dorit. Această problemă are o semnificație economică și umanitară imensă. Avem nevoie de o nouă modalitate de a dezvolta software-ul.

Principala problemă a dezvoltării software este risc.

Iată câteva exemple de risc.

Diagrame de fotografiere- Ziua livrării vine, și sunteți obligat să informați clientul că sistemul dezvoltat nu va fi pregătit pentru încă șase luni.

Închiderea proiectului- După mai multe schimburi ale programului și transferul datei de livrare, proiectul se închide, nici măcar a fost adus la etapa de testare în condițiile de muncă.

Sistemul își pierde utilitatea - Software-ul dezvoltat este stabilit cu succes într-un mediu de lucru real de producție, dar după o pereche de ani de utilizare, costul de a face schimbări la acesta și / sau numărul de defecte crește atât de mult încât devine mai ieftin să înlocuiască sistemul cu un nou dezvoltare.

- Sistemul software este instalat într-un mediu de lucru real de producție, dar numărul de defecte și deficiențe este atât de mare încât sistemul nu este utilizat.

- Sistemul software este instalat într-un mediu real de lucru de producție, cu toate acestea, se pare că, de fapt, nu rezolvă problema afacerii, pentru a rezolva inițial că intenționează inițial.

Schimbarea naturii afacerii - Sistemul software este instalat într-un mediu de lucru real de producție, cu toate acestea, în ultimele șase luni, problema pentru care acest sistem a fost intenționat să fie relevant și, în schimb, afacerea cu care se confruntă o nouă problemă și mai gravă.

Lipsa posibilităților - Sistemul software are multe caracteristici potențial interesante, fiecare dintre acestea fiind foarte frumos de programat, dar se pare că niciuna dintre aceste posibilități nu aduce prea multă beneficiu clientului.

Cadre de predare - timp de doi ani de muncă, toate programatori buniCine a lucrat la proiect, unul după altul a ridicat sistemul de programe dezvoltat și a mers la un alt loc de muncă.

Pe paginile acestei cărți veți citi despre programarea extremă ( programare extremă, XP) - Disciplina dezvoltării de software, care se concentrează pe reducerea gradului de risc la toate nivelurile procesului de dezvoltare. XP contribuie la o creștere semnificativă a productivității și la îmbunătățirea calității programelor dezvoltate, în plus, este o practică foarte ocupată care îi oferă tuturor participanților săi o mulțime de plăcere.

Cum reduce XP riscurile enumerate mai devreme?

Deplasare grafică - XP oferă pentru a utiliza un timp foarte scurt de eliberare a fiecărei versiuni următoare. Fiecare versiune obișnuită gata de utilizare a sistemului este dezvoltată timp de maximum câteva luni. Astfel, domeniul de activitate în cadrul fiecărei versiuni este limitat și, prin urmare, dacă se produce deplasarea, este mai puțin semnificativă. În cadrul fiecărei versiuni, se planifică emiterea mai multor iterații solicitate de oportunitățile clientului de a dezvolta fiecare dintre aceste iterații de la unu până la patru săptămâni. Acest lucru asigură feedback flexibil și sensibil cu clientul, astfel încât el primește o idee despre munca curentă. În cadrul fiecărei iterație, planificarea în conformitate cu XP se desfășoară în termeni de mai multe sarcini care trebuie rezolvate pentru a obține următoarea iterație. Soluția fiecăreia dintre sarcini este dată de una până la trei zile. Ca rezultat, comanda poate detecta și depana problemele chiar și în procesul de iterație. În cele din urmă, XP implică faptul că oportunitățile cu cea mai mare prioritate vor fi implementate mai întâi. Astfel, orice posibilități care nu au reușit să pună în aplicare în cadrul acestei versiuni regulate a produsului software au o prioritate mai mică.

Închiderea proiectului - În cadrul XP, Clientul trebuie să determine cel mai mic set permis de oportunități pe care versiunea minimă de lucru a programului trebuie să aibă un sentiment din punctul de vedere al soluționării sarcinilor de afaceri. Astfel, programatorii vor avea nevoie de efortul minim pentru ca clientul să înțeleagă dacă are nevoie de acest proiect sau nu.

Sistemul își pierde utilitatea - Ca parte a XP, sunt create și susținute un număr mare de teste, care sunt începute și reporneau după ce a făcut orice schimbare în sistem (de mai multe ori pe zi), datorită căreia este posibil să se monitorizeze cu atenție calitatea programului în curs de dezvoltare. XP acceptă în mod constant sistemul în stare excelentă. Defectele pur și simplu nu dau acumulate.

Numărul de defecte și deficiențe - În cadrul XP, sistemul dezvoltat este testat ca programatori care creează teste pentru fiecare funcție individuală dezvoltată și clienți care creează teste pentru fiecare capacitate individuală de sistem.

Lipsesc problema fiind rezolvată - Ca parte a XP, Clientul este o parte integrantă a echipei care lucrează la proiect. Specificația proiectului este reciclată în mod constant pe tot parcursul lucrărilor despre proiect, datorită acestei rafinării și descoperirilor, pe care clientul le raportează echipa de dezvoltare, își găsesc imediat reflecția în programul dezvoltat.

Programare extremă: dezvoltarea prin teste

Dedicat lui Cindy: aripile sufletului meu

Drepturile de publicare au fost obținute prin acord cu Addison-Wesley Longman. Toate drepturile rezervate. Nici o parte din această carte nu poate fi reprodusă în orice formă fără permisiunea scrisă a deținătorilor de drepturi de autor.

Informațiile conținute în această carte sunt obținute din sursele luate în considerare de către editor ca fiind fiabile. Cu toate acestea, având în vedere posibilele erori umane sau tehnice, editorul nu poate garanta acuratețea absolută și exhaustivitatea informațiilor și nu este responsabilă pentru posibilele erori legate de utilizarea cărții.

ISBN 978-0321146533 Engleză

ISBN 978-5-496-02570-6

Prefaţă

Cod pur care funcționează (Codul curat care funcționează) - în această frază scurtă, dar conținutul, inventată de RON Jeffers (RON Jeffries), se află întreaga semnificație a metodologiei de dezvoltare prin testarea (dezvoltarea bazată pe test, TDD). Un cod curat care funcționează este scopul la care merită să se străduiască deoarece

Aceasta este o modalitate previzibilă de a dezvolta programe. Știți când lucrarea poate fi considerată completă și nu vă faceți griji cu privire la o serie de erori lungi;

Oferă șansa de a învăța lecțiile pe care le prezintă codul. Dacă folosiți prima idee care a venit în minte, nu veți avea șansa de a realiza a doua idee mai bună;

Îmbunătățește durata de viață a utilizatorilor programelor dvs.;

Permite colegilor dvs. să se bazeze pe tine și pe tine - să se bazeze pe ele;

Scrieți un astfel de cod mai plăcut.

Dar cum să obțineți un cod pur care funcționează? Multe forțe interferează cu noi pentru a obține un cod curat și, uneori, nu este posibil să obțineți nici un cod care doar funcționează. Pentru a scăpa de multe probleme, vom dezvolta un cod bazat pe testarea automată. Acest stil de programare se numește testarea. Conform acestei tehnici

Noul cod este scris numai după un test automat care completează eșuează;

Orice duplicare este eliminată.

Două reguli simple, nu-i așa? Cu toate acestea, ele generează un comportament complex individual și de grup cu o multitudine de consecințe tehnice:

În procesul de proiectare, lansăm constant codul și primim o idee despre munca sa, ajută la luarea deciziilor corecte;

Noi scriem teste, pentru că nu putem aștepta ca altcineva să scrie teste pentru noi;

Mediul nostru de dezvoltare trebuie să răspundă rapid la modificările de coduri mici;

Proiectarea programului ar trebui să se bazeze pe utilizarea setului de componente autonome, slab legate pentru a simplifica testarea codului.

Cele două reguli TDD menționate determină procedura pentru etapele de programare.

1. Roșu - scrieți un mic test care nu funcționează și poate chiar nu este compilat.

2. Green - Faceți munca de testare cât mai repede posibil, nu vă gândiți la desemnarea designului și purității codului. Scrieți exact atât de mult cod, astfel încât testul să funcționeze.

3. Refactorizarea - Eliminați orice duplicare din codul scris.

Red - verde - refactorizarea este o mantra TDD.

Dacă presupunem că un astfel de stil de programare este posibil, se poate presupune că, datorită utilizării sale, codul va conține defecte semnificativ mai puține, în plus, scopul lucrării va fi clar pentru oricine participă la acesta. Dacă da, atunci dezvoltarea numai a codului necesar pentru a trece testele conduce, de asemenea, la consecințe sociale:

Cu o densitate suficient de scăzută a defectelor, asigurarea calității, QA va putea să se deplaseze de la răspuns la erori la avertizarea lor;

Cu o scădere a numărului de surprize neplăcute, managerii de proiect vor putea evalua mai precis costurile forței de muncă și vor implica clienții în procesul de dezvoltare;

Dacă subiectele discuțiilor tehnice sunt clar definite, programatorii pot interacționa în mod constant și mai mult de o dată pe zi sau o dată pe săptămână;

Și din nou, cu o densitate destul de scăzută a defectelor, putem primi un produs de lucru integrat, cu o nouă funcționalitate adăugată în fiecare zi, astfel încât să ne putem alătura clienților noștri în relația de afaceri a unui tip complet nou.

Deci, ideea este simplă, dar care este interesul nostru? De ce ar trebui un programator să-și asume o taxă suplimentară pentru a scrie teste automatizate? De ce să mutați programatorul să avanseze de lanțurile mici atunci când creierul său este capabil să se gândească la o structură de design mult mai complexă? Vitejie.

Vitejie

TDD este o modalitate de a gestiona frica în procesul de programare. Nu vreau să spun frica de a cădea de pe scaunul sau teama de cap. Vreau să spun frica de sarcină, "atât de complicată că nu am idee cum să o rezolv." Durerea este atunci când natura ne spune: "Opriți!" ,, Și frica este când Natura ne spune: "Fii atent!" Atenție nu este deloc rău, dar, în plus față de beneficii, frica are un impact negativ asupra noastră:

Frica ne face în avans și să ne gândim bine la ceva sau la o acțiune diferită;

Frica ne face să comunică mai puțin;

Frica ne face să ne fie frică de feedback despre munca noastră;

Frica ne face iritabili.

Nimic din acest lucru nu poate fi numit util pentru procesul de programare, mai ales dacă lucrați la o sarcină complexă. Deci, ne confruntă cu întrebarea despre cum să ieșim dintr-o situație dificilă și

Nu încercați să preziceți viitorul și să începeți imediat un studiu practic al problemei;

Nu fi corectați din restul lumii, ci pentru a crește nivelul de comunicare;

Nu evitați răspunsurile, dar, dimpotrivă, stabiliți un feedback fiabil și cu ajutorul său să monitorizați cu atenție rezultatele acțiunilor dvs.;

(Cu iritație, trebuie să te descurci cu tine).

Comparați programarea cu o găleată de bine. Cupa este umplută cu apă, rotiți maneta, înfășurați lanțul de pe poartă și ridicați găleata la etaj. Dacă o mică găleată este destul de potrivită pentru o poartă regulată, rotativă liberă. Dar dacă găleata este mare și tare, veți fi obosiți înainte de ao ridica. Pentru a obține posibilitatea de a se odihni între virajele pârghiei, este nevoie de un mecanism cu clichet, ceea ce vă permite să fixați pârghia. Cea mai dificilă găleată, cu atât mai des, dinții ar trebui să urmeze pe uneltele de clichet.

Testele din TDD sunt un dinți pe uneltele de clichet. Forțând testul la lucru, știm că acum funcționează testul, de acum înainte pentru totdeauna. Am devenit cu un pas mai aproape de finalizarea lucrării decât înainte de testul câștigat. După aceasta, am forțat să lucrăm al doilea test, apoi al treilea, al patrulea etc. Cu cât este mai dificilă problema cu care se confruntă programul, cu atât mai puține funcționalități ar trebui să acopere fiecare încercare.

Cititorii Cărți Programarea extremă a explicațiilorTrebuie să observe atenția asupra diferenței de ton între programarea extremă (programarea extremă, XP) și testarea prin testarea (dezvoltarea bazată pe test, TDD). Spre deosebire de XP, tehnica TDD nu este absolută. XP spune: "Pentru a continua, trebuie să învățați-o și ea". TDD este o tehnică mai puțin specifică. TDD presupune prezența unui interval între luarea deciziilor și obținerea rezultatelor și oferă instrumente pentru a controla durata acestui interval. "Ce se întâmplă dacă în timpul săptămânii voi proiecta un algoritm pe hârtie și apoi scriu codul, folosind abordarea" Primele teste "? Se va potrivi cu TDD? " Bineînțeles că va fi. Știți amploarea intervalului dintre luarea deciziilor și evaluarea rezultatelor și controlați conștient acest interval.

Majoritatea persoanelor care au stăpânit TDD susțin că practica lor de programare sa schimbat spre bine. Infectate cu teste (Test infectat) - O astfel de definiție a venit cu Erich Gamma (Erich Gamma) pentru a descrie această schimbare. După ce ați stăpânit TDD, descoperiți că scrieți mult mai multe teste decât înainte, și treceți mai departe de pașii mici, ceea ce vă va fi apărut fără sens. Pe de altă parte, unii programatori, care se familiarizează cu TDD, decid să revină la utilizarea practicilor anterioare, rezervând TDD ocazii speciale atunci când programarea obișnuită nu duce la progresul dorit.

Cu siguranță, există sarcini care sunt imposibile (cel puțin în acest moment) să rezolve numai cu teste. În special, TDD nu permite mecanic să demonstreze adecvarea codului dezvoltat în ceea ce privește securitatea datelor și fiabilitatea operațiunilor paralele. Desigur, siguranța se bazează pe un cod în care nu ar trebui să existe defecte, dar se bazează și pe participarea umană la procedurile de protecție a datelor. Problemele subțiri ale operațiunilor paralele sunt imposibil de reprodus cu încredere, purtând doar un cod.