Extreme Programming ( Extreme Programming , XP ) este una dintre metodologiile agile de dezvoltare software . Autorii metodologiei sunt Kent Beck , Ward Cunningham , Martin Fowler și alții.
Denumirea metodologiei vine de la ideea de a aplica metode și practici tradiționale utile de dezvoltare software, ducându-le la un nou nivel „extrem”. Deci, de exemplu, practica efectuării revizuirii codului , care constă în verificarea de către un programator a codului scris de un alt programator, în versiunea „extremă” este „programarea în perechi”, când un programator scrie cod, iar partenerul său la în același timp, revizuiește continuu exact codul scris.
Metodologia a fost dezvoltată de Kent Beck în timpul lucrului său la proiectul Chrysler Comprehensive Compensation System (C3) de salarizare . Beck a devenit specialistul principal în proiect în martie 1996. A început să îmbunătățească metodologia de dezvoltare folosită în proiect și a scris o carte despre aceasta, Extreme Programming Explained (publicată în octombrie 1999). [1] Proiectul a fost încheiat în februarie 2000.
Cele douăsprezece tehnici de bază de programare extremă (conform primei ediții a programării extreme explicate ) pot fi grupate în patru grupe:
XP presupune scrierea de teste automate (cod scris special pentru a testa logica altui cod). O atenție deosebită se acordă două tipuri de testare:
Un dezvoltator nu poate fi sigur de corectitudinea codului pe care îl scrie până când nu funcționează absolut toate testele unitare ale sistemului pe care îl dezvoltă. Testele unitare (testele unitare) permit dezvoltatorilor să se asigure că fiecare dintre ele în mod individual funcționează corect. De asemenea, îi ajută pe alți dezvoltatori să înțeleagă de ce este necesară o anumită bucată de cod și cum funcționează - în cursul studierii codului de testare, logica codului testat devine clară, deoarece este clar cum ar trebui să fie utilizat. Testele unitare permit, de asemenea, dezvoltatorului să refactoreze fără nicio teamă .
Testele funcționale sunt concepute pentru a testa funcționarea logicii formate prin interacțiunea mai multor părți (de multe ori de dimensiuni destul de impresionante). Sunt mai puțin detaliate decât testele unitare, dar acoperă mult mai mult - adică testele care, atunci când se execută, afectează o cantitate mai mare de cod, au, evident, șanse mai mari de a detecta orice comportament incorect. Din acest motiv, în programarea industrială, scrierea testelor funcționale are adesea prioritate față de scrierea testelor unitare.
Pentru XP, o abordare numită TDD (din limba engleză test-driven development - development through testing ) este o prioritate mai mare. În conformitate cu această abordare, este scris mai întâi un test care eșuează inițial (din moment ce logica pe care ar trebui să o verifice pur și simplu nu există încă), apoi logica necesară pentru ca testul să treacă este implementată. TDD, într-un sens, vă permite să scrieți cod care este mai convenabil de utilizat - pentru că atunci când scrieți un test, când nu există încă o logică, este cel mai ușor să aveți grijă de confortul viitorului sistem.
Scopul principal al jocului de planificare este de a forma rapid un plan de lucru brut și de a-l actualiza constant pe măsură ce condițiile sarcinii devin mai clare. Artefactele jocului de planificare sunt un set de carduri de hârtie care conțin dorințele clientului (poveștile clienților) și un plan de lucru brut pentru lansarea următoarei versiuni mici ale produsului. Factorul critic care face ca acest stil de planificare să fie eficient este că în acest caz clientul este responsabil pentru luarea deciziilor de afaceri, iar echipa de dezvoltare este responsabilă pentru luarea deciziilor tehnice. Dacă această regulă nu este respectată, întregul proces se destramă.
„Clientul” din XP nu este cel care plătește facturile, ci utilizatorul final al produsului software. XP susține că clientul trebuie să fie în contact tot timpul și să fie disponibil pentru întrebări.
Programarea în perechi presupune că tot codul este creat de perechi de programatori care lucrează pe același computer. Unul dintre ei lucrează direct cu textul programului, celălalt se uită la munca lui și urmărește imaginea de ansamblu a ceea ce se întâmplă. Dacă este necesar, tastatura este transferată liber de la una la alta. În timpul lucrului la un proiect, perechile nu sunt fixe: este recomandat să le amestecați, astfel încât fiecare programator din echipă să aibă o idee bună despre întregul sistem. Astfel, programarea în pereche îmbunătățește interacțiunea în cadrul echipei.
Dacă integrați suficient de des sistemul în curs de dezvoltare, puteți evita majoritatea problemelor asociate acestuia. În metodele tradiționale, integrarea, de regulă, se realizează chiar la sfârșitul lucrării asupra produsului, atunci când se consideră că toate componentele sistemului în curs de dezvoltare sunt complet gata. În XP, integrarea de cod a întregului sistem se realizează de mai multe ori pe zi, după ce dezvoltatorii s-au asigurat că toate testele unitare funcționează corect.
Refactorizarea este o tehnică de îmbunătățire a codului fără a-i schimba funcționalitatea. XP implică faptul că odată ce codul este scris, aproape sigur va fi refăcut de multe ori pe parcursul unui proiect. Dezvoltatorii XP reproșează fără milă codul scris anterior pentru a-l îmbunătăți. Acest proces se numește refactorizare. Lipsa acoperirii testelor provoacă respingerea refactorizării din cauza fricii de a rupe sistemul, ceea ce duce la degradarea treptată a codului.
Versiunile (lansările) ale produsului ar trebui să intre în producție cât mai des posibil. Lucrarea la fiecare versiune ar trebui să dureze cât mai puțin timp posibil. În același timp, fiecare versiune ar trebui să fie suficient de semnificativă în ceea ce privește utilitatea pentru afaceri.
Cu cât prima versiune funcțională a produsului este lansată mai devreme, cu atât mai devreme clientul începe să primească profit suplimentar din cauza acesteia. Amintiți-vă că banii câștigați astăzi valorează mai mult decât banii câștigați mâine. Cu cât clientul începe să folosească produsul mai devreme, cu atât mai devreme dezvoltatorii vor primi informații de la el despre ceea ce îndeplinește cerințele clientului. Aceste informații pot fi extrem de utile atunci când vă planificați următoarea lansare.
XP pornește de la faptul că, în timpul lucrului, condițiile problemei se pot schimba în mod repetat, ceea ce înseamnă că produsul dezvoltat nu trebuie proiectat în avans în întregime și complet. Încercarea de a proiecta sistemul în detaliu chiar la începutul lucrării este o pierdere de timp. XP sugerează că proiectarea este un proces atât de important încât trebuie făcut continuu pe toată durata de viață a proiectului. Proiectarea trebuie realizată în pași mici, ținând cont de cerințele în continuă schimbare. În fiecare moment, ar trebui să încercați să utilizați cel mai simplu design care se potrivește problemei curente și să îl modificați pe măsură ce condițiile problemei se schimbă.
Kent Beck și Martin Fowler [2] propun să descrie „designul simplu” ca fiind îndeplinirea următoarelor patru criterii:
Robert Martin este de acord [3] cu aceste reguli, dar în lucrarea sa anterioară [4] el sugerează, de asemenea, descrierea „designului simplu” cu următoarele trei principii:
Arhitectura este o reprezentare a componentelor unui sistem și a relațiilor lor între ele. Dezvoltatorii trebuie să analizeze arhitectura software pentru a înțelege unde din sistem trebuie să adauge noi funcționalități și cu ce va interacționa noua componentă.
Metafora sistemului este analogă cu ceea ce majoritatea tehnicilor numesc arhitectură. Metafora sistemului oferă echipei o idee despre cum funcționează sistemul în prezent, unde sunt adăugate noi componente și ce formă ar trebui să ia.
Alegerea unei metafore bune face ca echipa de dezvoltare să înțeleagă mai ușor cum funcționează sistemul. Uneori, acest lucru nu este ușor de făcut.
În acest moment, Bob Martin a recunoscut că metafora sistemului este depășită și ar trebui înlocuită cu Domain Driven Design .
Toți membrii echipei în timpul lucrului trebuie să respecte cerințele standardelor comune de codificare. Astfel:
Dacă echipa nu utilizează standarde uniforme de codare, devine mai dificil pentru dezvoltatori să refactorizeze; la schimbarea partenerilor în perechi, există mai multe dificultăți; în general, progresul proiectului este dificil. În cadrul XP, este necesar să fie dificil de înțeles cine este autorul acestei sau acelei bucăți de cod - întreaga echipă lucrează într-un mod unitar, ca o singură persoană. Echipa trebuie să formeze un set de reguli, iar apoi fiecare membru al echipei trebuie să respecte aceste reguli în timp ce scrie codul. Lista regulilor nu trebuie să fie exhaustivă sau prea voluminoasă. Sarcina este de a formula linii directoare generale care să facă codul ușor de înțeles pentru fiecare dintre membrii echipei. Standardul de codare ar trebui să fie simplu la început, apoi poate deveni treptat mai complex pe măsură ce echipa de dezvoltare câștigă experiență. Nu este nevoie să petreceți prea mult timp în elaborarea unui standard.
Proprietatea colectivă înseamnă că fiecare membru al echipei este responsabil pentru tot codul sursă . Astfel, toată lumea are dreptul de a face modificări în orice parte a programului. Programarea perechilor sprijină această practică: lucrând în perechi diferite, toți programatorii se familiarizează cu toate părțile codului sistemului. Un beneficiu important al deținerii codului colectiv este că accelerează procesul de dezvoltare, deoarece atunci când apare o eroare, orice programator îl poate remedia.
Dreptul fiecărui programator de a schimba codul riscă să fie introduse erori de către programatori care cred că știu ce fac, dar nu iau în considerare unele dependențe. Programatorii extremi cred că testele unitare bine definite rezolvă această problemă: dacă dependențele nerevizuite generează erori, atunci următoarea rulare a testelor unitare va eșua și va dezvălui problema.
| Dezvoltare de software | |
|---|---|
| Proces | |
Concepte de nivel înalt | |
| Directii |
|
| Metodologii de dezvoltare | |
| Modele |
|
Cifre notabile |
|