Esate susipažinęs su programavimu, tačiau ekstremalus programavimas (sutrumpintai XP) jums vis dar yra šiek tiek paslaptis.
Neleiskite, kad pavadinimas jus nuliūdintų, rizikuojate praleisti naudingą informaciją.
Šiame straipsnyje apžvelgsime viską, ką reikia žinoti apie ekstremalųjį programavimą, kad galėtumėte juo pasinaudoti.
Ekstremalus programavimas yra programinės įrangos kūrimo metodika, kuri yra dalis to, kas bendrai vadinama judriomis metodikomis. XP sukurta remiantis vertybėmis, principais ir praktika, o jos tikslas – sudaryti sąlygas mažoms ir vidutinėms komandoms gaminti aukštos kokybės programinę įrangą ir prisitaikyti prie nuolat kintančių ir kintančių reikalavimų.
XP skiriasi nuo kitų judrių metodikų tuo, kad XP pabrėžia techninius programinės įrangos kūrimo aspektus. Ekstremalus programavimas tiksliai apibūdina inžinierių darbą, nes laikantis inžinerinės praktikos komandos gali pateikti aukštos kokybės kodą tvariu tempu.
Trumpai tariant, ekstremalus programavimas yra geroji praktika, perkelta į kraštutinumą. Kadangi porinis programavimas yra geras, darykime tai visą laiką. Kadangi testavimas iš anksto yra geras, mes testuojame dar net neparašant gamybos kodo.
XP, skirtingai nei kitos metodikos, yra pagrįstas vertybėmis ir principais, kurie yra svarbūs ir svarbūs inžinerinės praktikos požiūriu.
Vertybės suteikia komandoms tikslą. Jie veikia kaip „šiaurinė žvaigždė“, kuri vadovauja jūsų sprendimams aukštu lygiu. Tačiau vertės yra abstrakčios ir per daug neaiškios, kad būtų galima konkretizuoti. Pavyzdžiui: sakydami, kad vertinate bendravimą, galite pasiekti daug skirtingų rezultatų.
Praktika tam tikra prasme yra priešinga vertybėms. Jos betoninės ir žemiškos, definustatyti, ką daryti. Praktika padeda komandoms prisiimti atsakomybę už vertybes. Pavyzdžiui, informacinių darbo erdvių praktika skatina skaidrų ir paprastą bendravimą.
Principai yra konkrečios srities gairės, kurios užpildo atotrūkį tarp praktikos ir vertybių.
XP vertybės: bendravimas, paprastumas, grįžtamasis ryšys, drąsa ir pagarba. Pažvelkime į kiekvieną iš jų išsamiau.
Rengimas BlogInnovazione.tai vaizdas alexsoft.com
Komunikacija: Bendravimo trūkumas neleidžia žinioms sklisti komandoje. Dažnai, kai iškyla problema, kažkas jau žino, kaip ją išspręsti. Tačiau bendravimo trūkumas neleidžia jiems sužinoti apie problemą ar prisidėti prie jos sprendimo. Taigi problema išspręsta du kartus ir susidaro atliekų.
Paprastumas: Paprastumas sako, kad jūs visada stengiatės padaryti paprasčiausią dalyką, kuris veikia. Tai dažnai klaidingai suprantama ir priimama kaip paprasčiausias dalykas, taškas, ignoruojant dalį „kas veikia“.
Taip pat svarbu atsiminti, kad paprastumas labai priklauso nuo konteksto. Tai, kas vienai komandai paprasta, kitai yra sudėtinga ir visiškai priklauso nuo kiekvienos komandos įgūdžių, patirties ir žinių.
grįžtamasis ryšys: Atsiliepimai apie tradicines, pakopines programinės įrangos kūrimo metodikas dažnai būna „per mažai, per vėlu“.
Tačiau XP priima pokyčius, o XP komandos siekia laiku ir nuolatinio grįžtamojo ryšio. Jei reikia kurso korekcijos, XPers nori sužinoti kuo greičiau.
Rengimas BlogInnovazione.tai vaizdas alexsoft.com
Atsiliepimai būna įvairių formų ir dydžių. Kai esate programavimo partneris, jūsų kolegos komentarai yra gyvybiškai svarbūs atsiliepimai. Taip pat ir kitų komandos narių nuomonė apie idėją, įskaitant klientą, kuris idealiu atveju yra komandos narys.
Testai yra dar vienas vertingų atsiliepimų šaltinis, kuris neapsiriboja bandymų rezultatais. Nesvarbu, ar testų rašymas lengvas, ar sunkus, taip pat grįžtamasis ryšys. Jei kyla problemų rašant testus, jūsų projektas tikriausiai per sudėtingas. Klausykite atsiliepimų ir supaprastinkite savo dizainą.
Kažkas, kas skamba kaip puiki idėja, praktiškai gali neveikti taip gerai. Taigi baigtas kodas taip pat yra grįžtamojo ryšio šaltinis, kaip ir paskirstytas produktas.
Galiausiai atminkite, kad atsiliepimų yra per daug. Jei komanda generuoja daugiau grįžtamojo ryšio, nei gali apdoroti, svarbūs atsiliepimai gali nukristi iš radaro. Taigi labai svarbu sulėtinti greitį ir išsiaiškinti, kas sukelia perteklinį grįžtamąjį ryšį, ir jį ištaisyti.
Drąsa: Kentas Bekas defidrąsa atsiranda kaip „veiksmingas veiksmas baimės akivaizdoje“. Kaip programinės įrangos inžinierius turite daug ko bijoti, todėl turite daug galimybių parodyti drąsą.
Reikia drąsos pasakyti tiesą, ypač nemalonią, pavyzdžiui, sąžiningus įvertinimus. Duoti ir gauti grįžtamąjį ryšį taip pat reikia drąsos. Reikia drąsos, kad nepakliūtum į paskendusių išlaidų klaidą ir atmesti nesėkmingą sprendimą, į kurį buvo investuota daug.
Pagarba: Pagrindinė XP prielaida yra ta, kad kiekvienas rūpinasi savo darbu. Jokia techninė kompetencija negali išgelbėti projekto, jei nėra rūpesčio ir pagarbos.
Kiekvienas žmogus yra vertas orumo ir pagarbos, ir tai, žinoma, apima žmones, dalyvaujančius programinės įrangos kūrimo projekte. Kai jūs ir jūsų komandos nariai gerbiate ir rūpinatės vieni kitais, klientu, projektu ir būsimais jo vartotojais, visi gauna naudos
Principai pateikia konkretesnius nurodymus nei vertybės. Tai yra gairės, kurios nušviečia vertybes ir daro jas aiškesnes bei ne tokias dviprasmiškas.
Rengimas BlogInnovazione.tai vaizdas alexsoft.com
Pavyzdžiui, remdamiesi vien drąsos verte, galite padaryti išvadą, kad patartina nedelsiant iš esmės pakeisti savo tvarkaraštį. Tačiau Baby Steps principas mums sako, kad dideli pokyčiai yra rizikingi. Taigi, pirmenybę teikite mažiems.
Žmoniškumas: Žmonės kuria programinę įrangą žmonėms, dažnai nepastebimas faktas. Tačiau atsižvelgiant į pagrindinius žmogaus poreikius, stipriąsias ir silpnąsias puses sukuriami produktai, kuriuos žmonės nori naudoti. O darbo aplinka, siūlanti pilnatvės ir augimo galimybę, priklausymo jausmą ir pagrindinį saugumą, yra vieta, kur lengviau atsižvelgi į kitų poreikius.
ekonomika: XP komandos visada atkreipia dėmesį į ekonomines programinės įrangos kūrimo realijas, nuolat vertina ekonomines rizikas ir projektų poreikius.
Pavyzdžiui, naudotojų istorijas jie įgyvendintų atsižvelgdami į jų verslo vertę, o ne į technines problemas.
Abipusė nauda: Po XP išvengiate sprendimų, kurie naudingi vienai šaliai kitos sąskaita. Pavyzdžiui, išplėstinės specifikacijos gali padėti kitiems tai suprasti, tačiau tai atitraukia jus nuo jų diegimo ir uždelsia tai padaryti naudotojams.
Abipusiai naudingas sprendimas yra naudoti automatinius priėmimo testus. Gaukite tiesioginį atsiliepimą apie įgyvendinimą, kolegos gauna tikslias kodo specifikacijas, o naudotojai pirmiausia gauna savo funkcijas. Be to, visi turėsite apsaugos tinklą nuo regresijos.
Nauda (abipusė nauda): Jei nurodytas sprendimas veikia viename lygyje, jis taip pat gali veikti aukštesniame arba žemesniame lygyje. Pavyzdžiui, naudojant XP įvairiais laipsniais kyla pavojus ankstyvam ir nuolatiniam atsiliepimui gauti.
Tobulinimas: Pagal tobulinimo principą, komandos siekia ne tobulumo pradiniame diegime, o pakankamai gero diegimo, o vėliau nuolat mokosi ir tobulina, remdamiesi realių vartotojų atsiliepimais.
Įvairovė: Jūs ir jūsų kolegos gauna naudos iš požiūrių, įgūdžių ir požiūrių įvairovės. Tokia įvairovė dažnai sukelia konfliktus, bet tai gerai.
Konfliktai ir nesutarimai yra galimybė atsirasti geresnėms idėjoms, kai visi vadovaujasi drąsos ir pagarbos vertybėmis. Drąsa reikšti priešingus požiūrius, pagarba juos išreiškiant pilietiškai ir empatiškai. Ir visa tai yra veiksmingas bendravimo pratimas.
Atspindys: Puikios komandos apmąsto savo darbą ir analizuoja, kaip būti geresniais. XP siūlo tam daugybę galimybių. Ne tik savaitės ir ketvirčio ciklais, bet ir kiekviena reklamuojama praktika.
Be loginės analizės, svarbu atsižvelgti ir į jausmus. Jūsų žarnynas gali jus informuoti prieš pradėdamas samprotauti. Ir taip jis gali kalbėtis su netechnikos žmonėmis, jie gali užduoti klausimus, kurie atveria visiškai naujas galimybes.
Srautas: Tradicinės programinės įrangos kūrimo metodikos turi atskiras fazes, kurios trunka ilgai ir turi mažai galimybių gauti grįžtamąjį ryšį bei kurso taisymą. Vietoj to, XP programinės įrangos kūrimas vyksta nuolatinėje veikloje, nuosekliame vertės „sraute“.
Galimybė: Kuriant programinę įrangą problemos neišvengiamos. Tačiau kiekviena problema yra galimybė tobulėti. Išmokite į juos žiūrėti tokiu būdu ir daug didesnė tikimybė, kad sugalvosite kūrybingus ir į tikslą orientuotus sprendimus, kurie taip pat padės išvengti jų pasikartojimo.
Perteklius: Atleidimo principas sako, kad jei tam tikra problema yra kritinė, turite naudoti daugybę taktikos, kad su ja kovotumėte.
Paimkite trūkumus. Nėra vienos taktikos, kuri galėtų užkirsti kelią visiems defektams ištrūkti iš gamybos.
Taigi XP sprendimas yra sukrauti kokybės priemonių rinkinį. Porinis programavimas, testavimas, nuolatinis integravimas. Kiekvienas iš jų yra viena gynybos linija, kartu beveik nepramušama siena.
Nesėkmė: nesėkmė nėra švaistymas, kai ji virsta žiniomis. Imtis veiksmų ir greitai išmokti tai, kas neveikia, yra daug produktyviau nei neveikimas dėl neapsisprendimo renkantis iš daugelio variantų.
Kokybė: Žmonės dažnai galvoja, kad yra dilema tarp kokybės ir greičio.
Yra atvirkščiai: siekdami gerinti kokybę, jūs einate greičiau.
Pavyzdžiui, pertvarkymas – kodo struktūros keitimas nekeičiant jo elgesio – yra praktika, kuri palengvina kodo supratimą ir pakeitimą. Dėl to mažiau tikėtina, kad turėsite kodo defektų, o tai leidžia pirmiausia suteikti daugiau vertės, nes nereikia taisyti klaidų.
Maži žingsneliai: Dideli pokyčiai yra rizikingi. XP sumažina šią riziką, atlikdama pakeitimus mažais žingsneliais kiekviename lygyje.
Programuotojai rašo kodą mažais žingsneliais naudodami testuojamą kūrimą. Jie integruoja savo kodą į pagrindinę liniją kelis kartus per dieną, o ne tik kas kelias savaites ar net mėnesius. Pats projektas vyksta trumpais ciklais, o ne ilgai trunkančiais etapais.
Atsakomybė priimta: XP sistemoje atsakomybė turi būti priimta, o ne priskiriama.
Atsakomybė turėtų būti kartu su įgaliojimais priimti sprendimus, už ką esate atsakingas. Taip pat yra priešingai. Jūs nenorite, kad žmonės priimtų sprendimus, jei jiems nereikia gyventi su jų pasekmėmis.
Ekstremalų programavimą, kaip judrią metodiką, galima priimti ir pradėti taikyti nesilaikant griežtų planų. Tai kartotinis dizainas, o ne didelis pradinis projektas.
XP gerokai skiriasi nuo tradicinių metodikų, t.y. kaskados, vengiant ilgai trunkančių fazių.
Kuo XP skiriasi nuo kitų judrių metodų?
Ekstremalus programavimas pagal savo pobūdį turi daug bendro su kitomis judriomis metodikomis, tačiau yra ir unikalus tarp jų.
Daugumoje kitų kūrimo metodikų apie tai, kaip atlikti darbą, daug nepasakoma. Kita vertus, XP yra labai nusiteikusi šiuo klausimu ir daug dėmesio skiria programinės įrangos inžinerijos praktikai.
„Scrum“ yra sistema, padedanti komandoms adaptaciniu būdu kurti sudėtingus projektus. „Scrum“ nediktuoja, kaip kūrėjai atlieka savo darbą. XP, kaip minėta, daug dėmesio skiria gerai programavimo praktikai.
Rengimas BlogInnovazione.lt Vaizdas tinkliniai sprendimai
Be to, XP akivaizdžiai susijęs su programavimu. Kita vertus, „Scrum“ gali būti taikomas bet kuriam projektui, kuriam naudingas pasikartojantis metodas.
XP priima savo komponentų pakeitimus. Komandos yra įgaliotos ir netgi skatinamos keisti praktiką, atsižvelgiant į jų konkrečius poreikius. Kita vertus, „Scrum Guide“ yra įsitikinęs, kad „nors galima įdiegti tik dalis Scrum, rezultatas nėra Scrum“.
Be to, „Scrum“ yra sistema, kurią reikia papildyti metodikomis ir praktika, kad darbas būtų atliktas.
Tai reiškia, kad labai rekomenduojama dirbti su ekstremaliu programavimu ir Scrum.
Pasak Kento Becko, subrendusi XP komanda neturėtų skirti griežtų vaidmenų, bet pripažinti, kad vaidmenys gali būti naudingi besikuriančioms komandoms, kol jos pradeda lėtėti arba apsunkinti bendradarbiavimą.
Pažvelkime į keletą pagrindinių vaidmenų:
Tai yra XP priimta praktika. Jie skirstomi į tris pagrindines grupes: programinės įrangos inžinerija, darbo vietos ir projektų valdymas.
Porinis programavimas: XP sistemoje kodą rašote poromis, sėdėdami ant mašinos. Jūs ir jūsų pora kalbatės vienas su kitu, kai analizuojate, diegiate ir išbandote funkciją, su kuria dirbate. Suporuotas programavimas yra ypač geras gaminant kodą su mažiau klaidų, tačiau vis tiek patrauklus, įdomus ir varginantis.
Dešimties minučių riba: Reikalingas Leidžiama 10 minučių sukurti visą projektą, įskaitant visų automatinių testų vykdymą, daugiausiai per dešimt minučių. Ši riba skirta tam, kad bandymai būtų supaprastinti ir veiksmingi.
Testai prieš programavimą: diegti funkcijas, taikydami metodą „pirmiausia bandymas“, dar vadinamą testu pagrįsta plėtra (TDD). TDD sudaro kūrimas naudojant paprastą iteracinę procedūrą:
TDD duoda keletą privalumų.
Pirma, atsiliepimai. Jei sunku parašyti testą, dizainas, kurio ieškote arba kurį paveldėjote, tikriausiai yra per sudėtingas ir jums reikia jį supaprastinti.
Antra, TDD leidžia programuotojams pasitikėti jų rašomu kodu ir sukuria gražų kilpos ritmą, kai kitas žingsnis visada yra aiškus.
Paskutinis, bet ne mažiau svarbus dalykas – TDD naudojimas nuo pat pradžių užtikrina 100 % kodo aprėptį. Tada bandymų rinkinys tikrai tampa apsauginiu tinklu būsimiems pakeitimams, skatinančiu kodo pertvarkymą ir sukuriančiu teigiamą kokybės ratą.
Inkrementinis dizainas: Laipsniško projektavimo praktika reiškia, kad kiekvieną dieną turite investuoti į programos dizainą, ieškant galimybių pašalinti dubliavimąsi ir atlikti nedidelius patobulinimus, kad pasiektumėte geriausią įmanomą dizainą, kurio šiandien reikia jūsų sistemai.
Nuolatinė integracija: XP sistemoje savo darbą integruojate į pagrindinę bendrinamą saugyklą kelis kartus per dieną, suaktyvindami automatinį visos sistemos kūrimą. Integravimas kuo anksčiau ir kuo dažniau labai sumažina integracijos išlaidas, nes sumažina susijungimų ir loginių konfliktų tikimybę. Tai taip pat atskleidžia aplinkos ir priklausomybės problemas.
Bendrinamas kodas (kolektyvinė nuosavybė): XP reklamuoja bendrinamą kodą arba kolektyvinę nuosavybę: kiekvienas kūrėjas yra atsakingas už visą kodą. Tai skatina keitimąsi informacija, mažina komandos magistralės faktorių ir padidina bendrą kiekvieno modulio kokybę, jei atsižvelgsime į įvairovės principą.
Viena CodeBase: Viena kodų bazė taip pat žinoma kaip „magistralės plėtra“. Tai reiškia, kad yra tik vienas tiesos šaltinis. Taigi, užuot ilgą laiką vystę atskirai, anksti ir dažnai sujunkite savo indėlį į vieną srautą. Funkcijų vėliavėlės padeda apriboti naudojimąsi funkcijomis, kol jos bus baigtos.
Kasdienis paskirstymas: diegimas gamyboje bent kartą per dieną yra logiška nuolatinės integracijos pasekmė:. Tiesą sakant, šiandien daugelis komandų žengia dar toliau ir praktikuoja nuolatinį diegimą. Tai reiškia, kad kiekvieną kartą, kai kas nors prisijungia prie pagrindinės linijos, programa įdiegiama gamyboje.
Kodas ir testai: Ši praktika reiškia, kad šaltinio kodas, įskaitant testus, yra vienintelis nuolatinis programinės įrangos projekto artefaktas. Kitų tipų artefaktų, įskaitant dokumentus, generavimas dažnai yra švaistomas, nes nesukuria tikros vertės klientui.
Jei jums reikia kitų artefaktų ar dokumentų, pasistenkite juos sugeneruoti iš gamybos kodo ir testų.
Pagrindinės priežasties analizė: Kai defektas patenka į gamybą, ne tik ištaisykite defektą. Įsitikinkite, kad išsiaiškinote, kas tai sukėlė, kodėl jums ir jūsų komandos draugams nepavyko išvengti slydimo. Tada imkitės veiksmų, kad tai nepasikartotų.
Sėdėkite kartu: XP komandoms labiau patinka dirbti kartu atviroje erdvėje. Ši praktika skatina bendravimą ir priklausomybės komandai jausmą.
Visa komanda: Visi, kurių reikia projekto sėkmei, yra XP komandos dalis. Tai labai priklauso nuo konteksto – kiekvienai komandai skirtinga – ir dinamiška, gali keistis komandoje.
Informacinės darbo erdvės: Informacinėje darbo erdvėje naudojama fizinė komandos erdvė, kad būtų rodoma informacija, leidžianti visiems iš pirmo žvilgsnio sužinoti projekto eigą. Tai, kaip tai daroma, gali skirtis – nuo fizinių pastabų ir grafikų iki ekrano kopijų, kuriose rodomos „Kanban“ lentos ir prietaisų skydeliai iš projektų valdymo programinės įrangos.
Energingas darbas: XP sistemoje dirbate tik tol, kol galite dirbti energingą darbą. Darbo valandų skaičius turi būti apribotas iki 40 valandų per savaitę.
ANALISI- Parašykite vartotojo reikalavimus formatu, žinomu kaip vartotojo analizė. Vartotojo analizė turi trumpą aprašomąjį pavadinimą ir trumpą aprašymą, ką reikia įgyvendinti.
Palaidas: Planuodami ciklą pridėkite smulkių užduočių, kurių komanda gali atsisakyti, jei iškils poreikis. Jei komanda pateikia per daug, visada galima pridėti daugiau istorijų.
Ciklai (mėnesinis ir savaitinis): XP plėtra vyksta dviem pagrindiniais ciklais: savaitės ir mėnesio ciklu.
Susitikimai, ciklai, suplanuoti leidimai: XP kūrimas vyksta dviem pagrindiniais ciklais: savaitės ciklu ir ketvirčio ciklu. Iš pradžių Kentas Beckas rekomendavo dviejų savaičių ciklą, tačiau antrajame savo knygos leidime jį pakeitė.
Savaitės ciklas: savaitinis ciklas yra XP projekto „pulsas“. Ciklas prasideda susitikimu, kurio metu klientas pasirenka, kokias istorijas jis nori sukurti per savaitę. Be to, komanda peržiūri savo darbą, įskaitant praėjusios savaitės pažangą, ir galvoja apie būdus, kaip pagerinti savo procesą.
Mėnesio ciklas: Kiekvieną mėnesį komanda apmąsto ir nustato tobulėjimo galimybes savo procese. Klientas pasirenka vieną ar kelias to mėnesio temas kartu su šių temų analize.
Kaip pradėti dirbti su ekstremaliu programavimu?
Gali būti sunku išmokti techninių įgūdžių ir XP įpročių. Kai kurios praktikos prie jų neįpratusiems programuotojams gali atrodyti svetimos.
Ercole Palmeri
Lavindami smulkiosios motorikos įgūdžius dažydami, vaikai paruošiami sudėtingesniems įgūdžiams, pavyzdžiui, rašymui. Norėdami nuspalvinti…
Karinio jūrų laivyno sektorius yra tikra pasaulinė ekonominė galia, kuri pasiekė 150 mlrd.
Praėjusį pirmadienį „Financial Times“ paskelbė apie susitarimą su „OpenAI“. FT licencijuoja savo pasaulinio lygio žurnalistiką…
Milijonai žmonių moka už srautinio perdavimo paslaugas, mokėdami mėnesinius abonentinius mokesčius. Paplitusi nuomonė, kad jūs…
