Programare extremă

Acest articol sau secțiune despre subiectul informaticii lipsește sau lipsește de note specifice și referințe bibliografice . Deși există o bibliografie și / sau link - uri externe , nu există nici o contextualizare a surselor cu note de subsol sau alte referințe precise care indică prompt originea informațiilor. Puteți îmbunătăți această intrare citând mai precis sursele . Urmați sfaturile de proiectare de referință .

Acest articol sau secțiune referitoare la informatică este considerat a fi verificat . Motiv : articolul este o traducere a articolului cu același nume în limba engleză, în care au fost eliminate părți fundamentale pentru înțelegerea subiectului. Conținutul, atunci când nu este greșit, este înșelător Alăturați-vă discuției și / sau corectați intrarea. Urmați sfaturile de proiectare de referință .

Programarea extremă (abreviată în XP ), o expresie engleză pentru programarea extremă , este o metodologie de dezvoltare software care pune accentul pe scrierea codului de calitate și viteza de răspuns la cerințele în schimbare. Aparține familiei metodologiilor agile și, ca atare, prescrie o dezvoltare iterativă și incrementală structurată în cicluri scurte de dezvoltare. Alte elemente cheie ale XP sunt programarea în perechi , utilizarea sistematică a testării unitare și refactorizarea , interzicerea programatorilor de a dezvolta cod inutil, accentul pus pe claritatea și simplitatea codului, preferința pentru structurile de management neierarhice și importanța acordată pentru a comunica direct și frecvent între dezvoltator și client și între dezvoltatori înșiși.

Reguli

Cele douăsprezece reguli (sau practici) care stau la baza programării extreme pot fi grupate în patru domenii.

Feedback la scară fină

• Programare pereche - Doi programatori lucrează împreună pe o stație de lucru, șoferul este cel care scrie codul în timp ce navigatorul se gândește la abordare și se gândește dacă poate funcționa. Acest lucru face ca codul produsului să fie de o calitate mai bună. Cei doi programatori trebuie să aibă aceeași experiență.
• Joc de planificare - este o întâlnire de planificare care are loc o dată pe iterație, de obicei o dată pe săptămână.
• Dezvoltare bazată peteste -testele automate (atât de unitate, cât și de acceptare ) sunt scrise înainte de a scrie codul.
• Toată echipa - în XP, „clientul” nu este cel care plătește factura, ci persoana care folosește efectiv sistemul. Clientul trebuie să fie prezent și disponibil pentru verificare (sunt recomandate întâlnirile săptămânale sau Jour fixe ).

Proces continuu

• Integrare continuă - Integrarea continuă a modificărilor de cod va evita întârzierile ulterioare în ciclul proiectului cauzate de probleme de integrare.
• Refactorizare sau îmbunătățire a designului - rescrierea codului fără modificarea funcționalității sale externe, schimbarea arhitecturii, pentru ao face mai simplă și mai generică.
• Versiuni mici - Software-ul este livrat prin lansări frecvente de funcții care creează valoare reală.

Înțelegere comună

• Standarde de codare - Alegeți și utilizați un standard de codare precis. Aceasta reprezintă un set convenit de reguli, pe care întreaga echipă de dezvoltare este de acord să le respecte pe tot parcursul proiectului.
• Deținerea codului colectiv - înseamnă că toată lumea este responsabilă pentru tot codul; prin urmare, oricine este implicat în proiect contribuie la redactare.
• Proiectare simplă - Programatorii ar trebui să utilizeze o abordare „ simplă este mai bună ” pentru proiectarea software-ului. Proiectarea la minimum și cu clientul.
• Metafora sistemului - descrie sistemul cu o metaforă, chiar și pentru descrierea formală. Aceasta poate fi văzută ca o poveste pe care toată lumea - clienți, programatori și manageri - o poate spune despre funcționarea sistemului.

Bunăstarea programatorilor

• Ritm durabil - conceptul este că programatorii sau dezvoltatorii de software nu ar trebui să lucreze mai mult de 40 de ore pe săptămână.

Model de proces

James Donovan Wells identifică patru linii directoare:

• comunicare (toată lumea poate vorbi cu toată lumea, chiar și ultimul dintre programatori cu clientul);
• simplitate (analiștii păstrează descrierea formală cât mai simplă și clară posibil);
• verificare (din prima zi când se testează codul);
• curaj (sistemul este pus în funcțiune cât mai curând posibil și modificările necesare sunt implementate treptat).

De asemenea, identifică patru faze ale proiectului, fiecare dintre acestea cu regulile sale interne:

• planificarea ( povestirile utilizatorilor , planificarea lansărilor , versiunile mici , viteza proiectului , factorul de încărcare , dezvoltarea iterativă , planificarea iterației , deplasarea oamenilor , întâlnirea zilnică în picioare , repararea XP );
• proiectare ( simplitate , metaforă a sistemului , carduri CRC , soluție spike , nu adăugați niciodată timpuriu , refactorizare );
• dezvoltare (Client întotdeauna disponibil, standarde, test de unitate mai întâi, programare în perechi, integrare secvențială, integrare des, proprietate de cod colectiv, optimizare ultimă, fără ore suplimentare);
• testare ( cadru de testare unitară , eroare găsită , test funcțional sau teste de acceptare ).

Bibliografie

• Kent Beck : Programare extremă explicată: Îmbrățișați schimbarea , Addison-Wesley, ISBN 0-201-61641-6
• Kent Beck : Programare extremă - Introducere , Addison-Wesley, ISBN 88-7192-088-0
• Alistair Cockburn : Agile Software Development , Addison-Wesley, ISBN 0-201-69969-9
• Kim Man Lui : Ritmuri de dezvoltare software , John Wiley și Sons, ISBN 0-470-07386-1

Elemente conexe

• Metodologie agilă
• Scrum (informatică)
• Programare pereche

Alte proiecte

• Wikimedia Commons conține imagini sau alte fișiere despre programare extremă

linkuri externe

• Programare extremă: o introducere ușoară. , pe extremeprogramming.org .
• Carlo Ghezzi, Mattia Monga, „Programare eXtreme: Programare extremă sau revizionism extremist?”, Mondo Digitale ( PDF ), pe mondodigitale.net . Adus la 20 ianuarie 2010 (arhivat din original la 29 decembrie 2009) .