Sunteți familiarizat cu programarea, dar Programarea extremă (XP pe scurt) este încă un mister pentru dvs.
Nu lăsați numele să vă dezamăgească, riscați să pierdeți informații utile.
În acest articol, vom acoperi tot ce trebuie să știți despre programarea extremă, astfel încât să o puteți folosi în avantajul dvs.
Programarea extremă este o metodologie de dezvoltare software care face parte din ceea ce este cunoscut în mod colectiv sub numele de metodologii agile. XP este construit pe valori, principii și practici, iar scopul său este de a permite echipelor mici și mijlocii să producă software de înaltă calitate și să se adapteze la cerințele în continuă schimbare și evoluție.
Ceea ce distinge XP de alte metodologii agile este faptul că XP pune accent pe aspectele tehnice ale dezvoltării software. Programarea extremă este precisă despre modul în care lucrează inginerii, deoarece respectarea practicilor de inginerie permite echipelor să livreze cod de înaltă calitate într-un ritm durabil.
Programarea extremă este, pe scurt, bune practici duse la extrem. Deoarece programarea perechilor este bună, să o facem tot timpul. Deoarece testarea în avans este bună, testăm înainte chiar să fie scris codul de producție.
XP, spre deosebire de alte metodologii, se bazează pe valori și principii care sunt importante și relevante, în ceea ce privește practicile de inginerie.
Valorile oferă un scop echipelor. Acţionează ca o „stea de nord” pentru a vă ghida deciziile la un nivel înalt. Cu toate acestea, valorile sunt abstracte și prea neclare pentru îndrumări specifice. De exemplu: a spune că prețuiești comunicarea poate duce la multe rezultate diferite.
Practicile sunt, într-un fel, opusul valorilor. Sunt beton și cu picioarele pe pământ, defistabilirea specificului a ceea ce trebuie făcut. Practicile ajută echipele să se considere responsabile pentru valori. De exemplu, practicarea spațiilor de lucru informaționale promovează comunicarea transparentă și simplă.
Principiile sunt linii directoare specifice domeniului care reduc decalajul dintre practici și valori.
Valori XP: comunicare, simplitate, feedback, curaj și respect. Să ne uităm la fiecare dintre ele mai detaliat.
redactare BlogInnovazione.aceasta a imaginii alexsoft. com
Comunicare: Lipsa de comunicare împiedică cunoștințele să circule în cadrul unei echipe. Adesea, când există o problemă, cineva știe deja cum să o rezolve. Dar lipsa de comunicare îi împiedică să învețe despre problemă sau să contribuie la rezolvarea acesteia. Astfel, problema ajunge să fie rezolvată de două ori, generând deșeuri.
Simplitate: Simplitatea spune că te străduiești întotdeauna să faci cel mai simplu lucru care funcționează. Este adesea înțeles greșit și luat drept cel mai simplu lucru, punct, ignorând partea „care funcționează”.
De asemenea, este vital să ne amintim că simplitatea este extrem de contextuală. Ceea ce este simplu pentru o echipă este complex pentru alta și depinde în totalitate de abilitățile, experiența și cunoștințele fiecărei echipe.
Feedback: Feedback-ul în metodologiile de dezvoltare software mai tradiționale, în cascadă, este adesea „prea puțin, prea târziu”.
XP, totuși, îmbrățișează schimbarea, iar echipele XP se străduiesc să obțină feedback la timp și constant. Dacă este necesară corectarea cursului, experții vor să afle cât mai curând posibil.
redactare BlogInnovazione.aceasta a imaginii alexsoft. com
Feedback-ul vine în multe forme și dimensiuni. Când sunteți partener de programare, comentariile colegului dvs. sunt feedback esențial. La fel și părerile altor membri ai echipei despre o idee, inclusiv clientul care, în mod ideal, este membru al echipei.
Testele sunt o altă sursă de feedback valoros care depășește rezultatele testelor. Indiferent dacă scrierea testelor este ușoară sau dificilă, la fel este și feedbackul. Dacă întâmpinați probleme la scrierea testelor, proiectul dvs. este probabil prea complex. Ascultați feedback-ul și eficientizați-vă designul.
Ceva care sună ca o idee grozavă poate să nu funcționeze atât de bine în practică. Prin urmare, codul finit este, de asemenea, o sursă de feedback, la fel ca un produs distribuit.
În cele din urmă, rețineți că există prea mult feedback. Dacă o echipă generează mai mult feedback decât poate suporta, feedback-ul important ar putea cădea de pe radar. Prin urmare, este esențial să încetinești și să descoperi ce cauzează excesul de feedback și să-l remediezi.
Curaj: Kent Beck deficurajul apare ca „acțiune eficientă în fața fricii”. Ca inginer software, ai multe de care te temi și, prin urmare, multe oportunități de a da dovadă de curaj.
Este nevoie de curaj pentru a spune adevărul, mai ales pe cele neplăcute, precum estimările oneste. A oferi și a primi feedback necesită și curaj. Și este nevoie de curaj pentru a evita căderea în eroarea costurilor scufundate și a renunța la o soluție eșuată care a primit investiții substanțiale.
Respect: O premisă fundamentală a XP este că tuturor le pasă de munca lor. Nicio excelență tehnică nu poate salva un proiect dacă nu există grijă și respect.
Fiecare persoană este demnă de demnitate și respect, iar asta include, desigur, persoanele implicate într-un proiect de dezvoltare software. Când tu și membrii echipei tale vă respectați și aveți grijă unul de celălalt, de client, de proiect și de viitorii săi utilizatori, toată lumea beneficiază
Principiile oferă îndrumări mai specifice decât valorile. Sunt linii directoare care luminează valorile și le fac mai explicite și mai puțin ambigue.
redactare BlogInnovazione.aceasta a imaginii alexsoft. com
De exemplu, doar pe baza valorii curajului, ați putea concluziona că este recomandabil să faceți imediat o schimbare majoră în programul dvs. Totuși, principiul Baby Steps ne spune că schimbările mari sunt riscante. Deci, preferați-le pe cele mici.
Umanitate: Oamenii creează software pentru oameni, un fapt adesea trecut cu vederea. Dar luând în considerare nevoile umane de bază, punctele forte și punctele slabe, creează produse pe care oamenii doresc să le folosească. Iar un mediu de lucru care îți oferă oportunitatea de împlinire și creștere, sentimentul de apartenență și securitate de bază, este un loc în care iei mai ușor în considerare nevoile celorlalți.
economie: În XP, echipele acordă întotdeauna atenție realităților economice ale dezvoltării software, evaluează constant riscurile economice și nevoile proiectelor.
De exemplu, ar implementa poveștile utilizatorilor în funcție de valoarea lor de afaceri, mai degrabă decât de preocupările tehnice.
Beneficiu mutual: După XP, eviți soluțiile care beneficiază o parte în detrimentul alteia. De exemplu, specificațiile extinse ar putea ajuta pe altcineva să o înțeleagă, dar vă distrage atenția de la implementarea acesteia și o întârzie pentru utilizatorii dvs.
O soluție reciproc avantajoasă este utilizarea testelor de acceptare automate. Obțineți feedback instantaneu cu privire la implementarea dvs., colegii dvs. primesc specificații precise în cod, iar utilizatorii primesc mai întâi funcțiile lor. În plus, toți veți avea o plasă de siguranță împotriva regresiilor.
Beneficiu (beneficiu reciproc): Dacă o anumită soluție funcționează la un nivel, poate funcționa și la un nivel superior sau inferior. De exemplu, obținerea de feedback din timp și constant este în joc în diferite grade în XP.
Îmbunătăţire: Conform principiului îmbunătățirii, echipele nu urmăresc perfecțiunea într-o implementare inițială, ci o implementare suficient de bună, apoi învață și îmbunătățește continuu cu feedback de la utilizatori reali.
Diversitate: Tu și colegii tăi beneficiezi de o diversitate de perspective, abilități și atitudini. O astfel de diversitate duce adesea la conflicte, dar este în regulă.
Conflictul și dezacordul sunt oportunități pentru ca idei mai bune să apară atunci când toată lumea joacă după valorile curajului și respectului. Curajul de a exprima puncte de vedere opuse, respect în exprimarea lor într-un mod civil și empatic. Și toate acestea sunt un exercițiu de comunicare eficient.
Reflecţie: Echipele grozave reflectă asupra muncii lor și analizează cum să fie mai buni. XP oferă multe oportunități în acest sens. Nu doar în ciclurile săptămânale și trimestriale, ci în fiecare practică pe care o promovează.
Sentimentele sunt importante de luat în considerare pe lângă analiza logică. Instinctul tău te poate informa înainte de a putea argumenta despre ceva. Și astfel el poate vorbi cu oameni netehnici, pot pune întrebări care deschid posibilități complet noi.
curgere: Metodologiile tradiționale de dezvoltare software au faze distincte, care durează mult timp și au puține oportunități de feedback și corectare a cursului. În schimb, dezvoltarea de software în XP are loc în activități care au loc continuu, într-un „flux” consistent de valoare.
Şansă: Problemele sunt inevitabile în dezvoltarea de software. Cu toate acestea, fiecare problemă este o oportunitate de îmbunătățire. Învață să le privești în acest fel și este mult mai probabil să vii cu soluții creative și orientate spre obiective, care servesc, de asemenea, să prevină ca acestea să se repete.
Redundanţă: Principiul redundanței spune că, dacă o anumită problemă este critică, trebuie să folosiți multe tactici pentru a o contracara.
Luați defectele. Nu există o singură tactică care să împiedice toate defectele să scape de producție.
Deci, soluția XP este să stivuiască un set de măsuri de calitate. Programare perechi, testare, integrare continuă. Fiecare o singură linie de apărare, împreună un zid practic impenetrabil.
eșec: eșecul nu este o risipă când se traduce în cunoștințe. A acționa și a învăța rapid ceea ce nu funcționează este mult mai productiv decât inacțiunea cauzată de indecizia în alegerea dintre multe opțiuni.
Calitate: Oamenii cred adesea că există o dilemă între calitate și viteză.
Este invers: împingerea pentru îmbunătățirea calității este ceea ce te face să mergi mai repede.
De exemplu, refactorizarea - schimbarea structurii codului fără a-i schimba comportamentul - este o practică care face codul mai ușor de înțeles și schimbat. Ca urmare, este mai puțin probabil să introduceți defecte de cod, ceea ce vă permite să oferiți mai întâi valoare, fără a fi nevoit să remediați erorile.
Pași mici: Schimbările mari sunt riscante. XP atenuează acest risc făcând modificări în pași mici, la fiecare nivel.
Programatorii scriu cod în pași mici folosind dezvoltarea bazată pe teste. Ei își integrează codul în linia principală de mai multe ori pe zi, în loc de doar la câteva săptămâni sau chiar luni. Proiectul în sine are loc în cicluri scurte, mai degrabă decât în faze de lungă durată.
Responsabilitate acceptată: În XP, responsabilitatea ar trebui acceptată, niciodată atribuită.
Responsabilitatea ar trebui să vină cu autoritatea de a lua decizii cu privire la ceea ce ești responsabil. Este adevărat și contrariul. Nu vrei ca oamenii să ia decizii dacă nu trebuie să trăiască cu consecințele lor.
Programarea extremă, fiind o metodologie agilă, poate fi acceptată și început să o adopte fără a urma planuri rigide. Acesta este un design iterativ mai degrabă decât un mare proiect inițial.
XP diferă semnificativ de metodologiile tradiționale, adică în cascadă, evitând fazele de lungă durată.
Prin ce diferă XP de alte metodologii agile?
Programarea extremă, prin natura sa, are multe în comun cu alte metodologii agile, dar este și unică printre ele.
Majoritatea celorlalte metodologii de dezvoltare nu spun prea multe, dacă ceva, despre cum să duci la bun sfârșit treaba. XP, pe de altă parte, este foarte obișnuit când vine vorba de acest lucru și pune mare accent pe practicile de inginerie software.
Scrum este un cadru pentru a ajuta echipele să dezvolte proiecte complexe într-un mod adaptativ. Scrum nu dictează modul în care dezvoltatorii își fac munca. XP, după cum am menționat, pune mult accent pe bunele practici de programare.
redactare BlogInnovazione.ro Imagine solutii nete
De asemenea, XP este evident despre programare. Scrum, pe de altă parte, poate fi aplicat oricărui proiect care beneficiază de o abordare iterativă.
XP acceptă modificări ale componentelor sale. Echipele sunt împuternicite și chiar încurajate să modifice practicile în funcție de nevoile lor specifice. Ghidul Scrum, pe de altă parte, este ferm că „Deși numai părți din Scrum pot fi implementate, rezultatul nu este Scrum”.
De asemenea, Scrum este un cadru care trebuie completat cu metodologii și practici pentru a face treaba.
Aceasta înseamnă că lucrul în programare extremă și Scrum este foarte recomandat.
Potrivit lui Kent Beck, o echipă XP matură nu ar trebui să atribuie roluri rigide, ci să recunoască faptul că rolurile pot fi utile echipelor în curs de dezvoltare până când acestea încep să încetinească sau să îngreuneze colaborarea.
Să ne uităm la câteva roluri cheie:
Acestea sunt practicile adoptate în XP. Acestea sunt împărțite în trei grupuri principale: inginerie software, la locul de muncă și management de proiect.
Programare pereche: În XP, scrieți codul în perechi pe o mașină. Tu și cuplul tău vorbiți unul cu celălalt în timp ce analizați, implementați și testați funcția la care lucrați. Programarea în pereche este deosebit de bună pentru a produce cod cu mai puține erori, în același timp fiind captivantă, distractivă și obositoare.
Limită de zece minute: Necesar Permite 10 minute pentru construirea întregului proiect, inclusiv rularea tuturor testelor automate, în maximum zece minute. Această limită este de a menține testarea eficientă și eficientă.
Teste înainte de programare: implementați caracteristici folosind abordarea primul test, numită și dezvoltare bazată pe teste (TDD). TDD constă în dezvoltare folosind o procedură iterativă simplă:
TDD aduce mai multe beneficii.
În primul rând, feedback. Dacă este dificil să scrieți un test, designul pe care îl căutați sau pe care l-ați moștenit este probabil prea complex și trebuie să îl simplificați.
În al doilea rând, TDD le permite programatorilor să aibă încredere în codul pe care îl scriu și creează un ritm de buclă plăcut în care următorul pas este întotdeauna clar.
Nu în ultimul rând, utilizarea TDD de la început asigură o acoperire de cod de 100%. Suita de teste devine apoi cu adevărat o plasă de siguranță pentru schimbările viitoare, încurajând refactorizarea codului și creând un cerc virtuos al calității.
Design incremental: Practica designului incremental înseamnă că trebuie să investiți în designul aplicației dvs. în fiecare zi, căutând oportunități de a elimina dublarea și de a face mici îmbunătățiri pentru a obține cel mai bun design posibil pentru ceea ce are nevoie sistemul dvs. astăzi.
Integrare continuă: În XP, vă integrați munca în depozitul partajat principal de mai multe ori pe zi, declanșând o construcție automată a întregului sistem. Integrarea cât mai devreme și cât mai des posibil reduce drastic costul integrării, deoarece face ca fuziunile și conflictele logice să apară mai puțin probabil. De asemenea, expune probleme de mediu și dependență.
Cod comun (proprietate colectivă): XP promovează codul partajat sau proprietatea colectivă: fiecare dezvoltator este responsabil pentru tot codul. Încurajează schimbul de informații, reduce factorul magistralei echipei și crește calitatea generală a fiecărui modul dacă luăm în considerare principiul diversității.
Single CodeBase: O bază de cod unică este cunoscută și ca „dezvoltare bazată pe trunk”. Înseamnă că există o singură sursă de adevăr. Deci, în loc să vă dezvoltați izolat pentru perioade lungi de timp, îmbinați contribuțiile într-un singur flux devreme și frecvent. Indicatorii de caracteristici vă ajută să vă limitați utilizarea funcțiilor până când acestea sunt complete.
Distributie zilnica: implementarea în producție cel puțin o dată pe zi este o consecință logică a integrării continue:. De fapt, astăzi, multe echipe merg și mai departe și practică implementarea continuă. Adică, ori de câte ori cineva se alătură liniei principale, aplicația este implementată în producție.
Cod și teste: Această practică înseamnă că codul sursă, inclusiv testele, este singurul artefact permanent al unui proiect software. Implicarea în generarea altor tipuri de artefacte, inclusiv documentare, este adesea o risipă, deoarece nu generează valoare reală pentru client.
Dacă aveți nevoie de alte artefacte sau documente, faceți un efort pentru a le genera din codul de producție și teste.
Analiza cauzelor fundamentale: Ori de câte ori un defect intră în producție, nu doar corectați defectul. Asigurați-vă că vă dați seama ce a cauzat, în primul rând, de ce tu și colegii tăi nu ați reușit să împiedicați derapajul. Apoi, luați măsuri pentru a vă asigura că nu se va mai întâmpla.
Stați împreună: În XP, echipele preferă să lucreze împreună într-un spațiu deschis. Această practică promovează comunicarea și un sentiment de apartenență la o echipă.
Întreaga echipă: Toți cei care sunt necesari pentru succesul proiectului fac parte din echipa XP. Acesta este foarte contextual – diferit pentru fiecare echipă – și dinamic, se poate schimba în cadrul unei echipe.
Spații de lucru informaționale: Un spațiu de lucru informațional folosește spațiul fizic al echipei pentru a afișa informații care permit oricui să cunoască, dintr-o privire, progresul proiectului. Modul în care se face acest lucru poate varia, de la note fizice și grafice la capturi de ecran care arată panouri Kanban și tablouri de bord din software-ul de management al proiectelor.
Munca energizata: În XP, lucrezi doar atâta timp cât poți face o muncă energică. Orele de lucru trebuie să fie limitate la 40 pe săptămână, maxim.
Analisi- Scrieți cerințele utilizatorului într-un format cunoscut sub numele de analiză a utilizatorilor. O analiză a utilizatorului are un nume scurt, descriptiv și, de asemenea, o scurtă descriere a ceea ce trebuie implementat.
Moale: Când planificați un ciclu, adăugați sarcini minore pe care echipa le poate abandona dacă este nevoie. Mai multe povești pot fi întotdeauna adăugate dacă echipa oferă prea mult.
Cicluri (lunare și săptămânale): Dezvoltarea în XP are loc în două cicluri principale: ciclul săptămânal și ciclul lunar.
Întâlniri, cicluri, lansări programate: Dezvoltarea în XP funcționează în două cicluri principale: ciclul săptămânal și ciclul trimestrial. Inițial, Kent Beck a recomandat un ciclu de două săptămâni, dar a schimbat asta în a doua ediție a cărții sale.
Ciclu săptămânal: ciclul săptămânal este „pulsul” unui proiect XP. Ciclul începe cu o întâlnire în care clientul alege ce povești dorește să creeze în timpul săptămânii. În plus, echipa își revizuiește munca, inclusiv progresul de săptămâna trecută și se gândește la modalități de a-și îmbunătăți procesul.
Ciclu lunar: În fiecare lună, echipa reflectă și identifică oportunități de îmbunătățire în procesul lor. Clientul alege una sau mai multe teme pentru luna respectivă, împreună cu analizele din aceste teme.
Cum să începeți să lucrați cu programare extremă?
Abilitățile tehnice și obiceiurile XP pot fi greu de învățat. Unele dintre practici pot părea străine pentru programatorii neobișnuiți cu ele.
Ercole Palmeri
Luni trecută, Financial Times a anunțat un acord cu OpenAI. FT își licențiază jurnalismul de clasă mondială...
Milioane de oameni plătesc pentru serviciile de streaming, plătind taxe lunare de abonament. Este o părere comună că tu...
Coveware de la Veeam va continua să ofere servicii de răspuns la incidente de extorcare cibernetică. Coveware va oferi capacități criminalistice și de remediere...
Întreținerea predictivă revoluționează sectorul petrolului și gazelor, cu o abordare inovatoare și proactivă a managementului uzinelor...
