Olete programmeerimisega tuttav, kuid ekstreemprogrammeerimine (lühidalt XP) on teie jaoks endiselt pisut mõistatus.
Ära lase nimel end häirida, riskid kasulikust teabest ilma jääda.
Selles artiklis käsitleme kõike, mida peate Extreme Programmingi kohta teadma, et saaksite seda oma eeliseks kasutada.
Ekstreemprogrammeerimine on tarkvaraarenduse metoodika, mis on osa nn agiilsetest metoodikatest. XP on üles ehitatud väärtustele, põhimõtetele ja tavadele ning selle eesmärk on võimaldada väikestel ja keskmise suurusega meeskondadel toota kvaliteetset tarkvara ning kohaneda pidevalt muutuvate ja arenevate nõuetega.
XP-d eristab teistest agiilsetest metoodikatest see, et XP rõhutab tarkvaraarenduse tehnilisi aspekte. Ekstreemne programmeerimine on täpne selle kohta, kuidas insenerid töötavad, kuna inseneritavade järgimine võimaldab meeskondadel pakkuda kvaliteetset koodi jätkusuutlikus tempos.
Ekstreemprogrammeerimine on lühidalt öeldes head tavad, mis on viidud äärmuseni. Kuna paarisprogrammeerimine on hea, siis teeme seda kogu aeg. Kuna eelnevalt testimine on hea, siis testime enne tootmiskoodi kirjutamist.
Erinevalt teistest metoodikatest põhineb XP väärtustel ja põhimõtetel, mis on inseneritavade seisukohast olulised ja asjakohased.
Väärtused annavad meeskondadele eesmärgi. Nad toimivad "põhjatähena", mis juhib teie otsuseid kõrgel tasemel. Väärtused on aga abstraktsed ja konkreetsete juhiste jaoks liiga hägused. Näiteks: ütlemine, et väärtustate suhtlemist, võib viia paljude erinevate tulemusteni.
Praktikad on teatud mõttes väärtuste vastandid. Need on konkreetsed ja maalähedased, defitehtavate üksikasjade määramine. Tavad aitavad meeskondadel väärtuste eest vastutada. Näiteks infotööruumide praktika soodustab läbipaistvat ja lihtsat suhtlust.
Põhimõtted on valdkonnapõhised juhised, mis ületavad lõhe tavade ja väärtuste vahel.
XP väärtused: suhtlemine, lihtsus, tagasiside, julgus ja austus. Vaatame igaüks neist üksikasjalikumalt.
Koostamine BlogInnovazione.see pildist alexsoft.com
kommunikatsioon: Suhtlemise puudumine takistab teadmiste liikumist meeskonnas. Sageli, kui probleem tekib, teab keegi juba, kuidas seda parandada. Kuid suhtlemise puudumine ei lase neil probleemist teada saada või selle lahendamisele kaasa aidata. Seega lahendatakse probleem kahekordselt, tekitades jäätmeid.
Lihtsus: Lihtsus ütleb, et püüate alati teha kõige lihtsamat, mis töötab. Seda mõistetakse sageli valesti ja võetakse kui kõige lihtsamat asja, punkt, jättes tähelepanuta "mis töötab" osa.
Samuti on oluline meeles pidada, et lihtsus sõltub suuresti kontekstist. Mis on ühe meeskonna jaoks lihtne, on teise jaoks keeruline ja sõltub täielikult iga meeskonna oskustest, kogemustest ja teadmistest.
tagasiside: Tagasiside traditsioonilisemate, kaskaadsete tarkvaraarenduse metoodikate puhul on sageli "liiga vähe, liiga hilja".
XP aga hõlmab muutusi ja XP meeskonnad püüdlevad õigeaegse ja pideva tagasiside saamiseks. Kui on vaja kursi korrigeerimist, tahavad XPerid sellest võimalikult kiiresti teada saada.
Koostamine BlogInnovazione.see pildist alexsoft.com
Tagasiside on mitmesuguse kuju ja suurusega. Kui olete programmeerimise partner, on teie kolleegi kommentaarid ülioluline tagasiside. Nii on ka teiste meeskonnaliikmete arvamus idee kohta, sealhulgas klient, kes ideaalis on meeskonna liige.
Testid on veel üks väärtusliku tagasiside allikas, mis läheb kaugemale testitulemustest. Kas testide kirjutamine on lihtne või raske, on ka tagasiside. Kui teil on probleeme testide kirjutamisega, on teie projekt tõenäoliselt liiga keeruline. Kuulake tagasisidet ja täiustage oma disaini.
Miski, mis kõlab suurepärase ideena, ei pruugi praktikas nii hästi toimida. Seega on valmis kood samuti tagasiside allikas, nagu ka hajutatud toode.
Lõpuks pidage meeles, et tagasisidet on liiga palju. Kui meeskond genereerib rohkem tagasisidet, kui ta suudab vastu võtta, võib oluline tagasiside radarilt välja kukkuda. Seega on oluline aeglustada ja välja selgitada, mis põhjustab liigset tagasisidet, ja see parandada.
Julgus: Kent Beck defijulgus ilmneb kui "tõhus tegevus hirmuga silmitsi seistes". Tarkvarainsenerina on sul palju karta ja seega rohkelt võimalusi julgust üles näidata.
Tõde, eriti ebameeldivate, näiteks ausate hinnangute rääkimine nõuab julgust. Ka tagasiside andmine ja saamine nõuab julgust. Ja selleks on vaja julgust, et vältida kukkumiskulude eksitust ja loobuda ebaõnnestunud lahendusest, mis on saanud märkimisväärseid investeeringuid.
Austa: XP põhieeldus on, et kõik hoolivad oma tööst. Ükski tehniline tipptase ei päästa projekti, kui puudub hoolitsus ja austus.
Iga inimene on väärt väärikust ja austust ning selle alla kuuluvad loomulikult ka tarkvaraarenduse projektiga seotud inimesed. Kui teie ja teie meeskonnaliikmed austate ja hoolite üksteisest, kliendist, projektist ja selle tulevastest kasutajatest, võidavad kõik
Põhimõtted annavad täpsema juhise kui väärtused. Need on juhised, mis valgustavad väärtusi ning muudavad need selgesõnalisemaks ja vähem mitmetähenduslikuks.
Koostamine BlogInnovazione.see pildist alexsoft.com
Näiteks ainuüksi julguse väärtuse põhjal võite järeldada, et soovitav on oma ajakavas kohe suuri muudatusi teha. Kuid Baby Stepsi põhimõte ütleb meile, et suured muutused on riskantsed. Seega eelista pigem väikseid.
Inimlikkus: Inimesed loovad inimestele tarkvara, mis on sageli tähelepanuta jäetud fakt. Kuid inimeste põhivajaduste, tugevate ja nõrkade külgede arvestamine loob tooteid, mida inimesed soovivad kasutada. Ning eneseteostus- ja kasvamisvõimalust, kuuluvustunnet ja elementaarset turvatunnet pakkuv töökeskkond on koht, kus arvestad kergemini teiste vajadustega.
Majandus: XP-s pööravad meeskonnad alati tähelepanu tarkvaraarenduse majanduslikule tegelikkusele, hindavad pidevalt majandusriske ja projektivajadusi.
Näiteks rakendaksid nad kasutajalugusid nende äriväärtuse, mitte tehniliste probleemide põhjal.
Mõlemapoolne kasu: Pärast XP-d väldid lahendusi, mis toovad ühe osapoole kasu teise arvelt. Näiteks võivad laiendatud spetsifikatsioonid aidata kellelgi teisel seda mõista, kuid see segab teid selle rakendamisest ja lükkab teie kasutajate jaoks edasi.
Vastastikuselt kasulik lahendus on automatiseeritud vastuvõtutestide kasutamine. Saate oma juurutamise kohta kohest tagasisidet, teie kolleegid saavad koodis täpsed spetsifikatsioonid ja kasutajad saavad kõigepealt nende funktsioonidest aru. Lisaks on teil kõigil turvavõrk regressioonide vastu.
Kasu (vastastikune kasu): kui antud lahendus töötab ühel tasemel, võib see töötada ka kõrgemal või madalamal tasemel. Näiteks varajane ja pidev tagasiside saamine on XP-s erineval määral kaalul.
Parandamine: Täiustamise põhimõtte kohaselt ei sihi meeskonnad mitte esialgses juurutuses täiuslikkust, vaid piisavalt head teostust, mida siis reaalsetelt kasutajatelt saadud tagasiside põhjal pidevalt edasi õpivad ja täiustavad.
Mitmekesisus: Teie ja teie kolleegid saavad kasu vaatenurkade, oskuste ja hoiakute mitmekesisusest. Selline mitmekesisus põhjustab sageli konflikte, kuid see on okei.
Konfliktid ja lahkarvamused on võimalused paremate ideede tekkeks, kui kõik mängivad julguse ja austuse väärtuste järgi. Julgus väljendada vastandlikke seisukohti, austus nende väljendamisel kodaniku- ja empaatiliselt. Ja kõik see on tõhus suhtlusharjutus.
Peegeldus: Suurepärased meeskonnad peegeldavad oma tööd ja analüüsivad, kuidas olla parem. XP pakub selleks palju võimalusi. Mitte ainult nädala- ja kvartalitsüklites, vaid igas praktikas, mida see edendab.
Lisaks loogilisele analüüsile on oluline arvestada ka tundeid. Teie sisetunne suudab teid teavitada enne, kui jõuate millegi üle arutleda. Ja nii saab ta rääkida mittetehniliste inimestega, nad saavad esitada küsimusi, mis avavad täiesti uusi võimalusi.
Voolu: Traditsioonilistel tarkvaraarenduse metoodikatel on erinevad faasid, mis kestavad kaua ning neil on vähe võimalusi tagasisideks ja kursuse korrigeerimiseks. Selle asemel toimub XP-s tarkvaraarendus tegevustes, mis toimuvad pidevalt, järjepidevas väärtuse "voos".
Võimalus: Tarkvaraarenduses on probleemid vältimatud. Iga probleem on aga võimalus paranemiseks. Õppige neid niimoodi vaatama ja leiate palju tõenäolisemalt loomingulisi ja eesmärgipäraseid lahendusi, mis takistavad ka nende kordumist.
Koondamine: koondamise põhimõte ütleb, et kui antud probleem on kriitiline, peate selle vastu võitlemiseks kasutama mitmeid taktikaid.
Võtke vead. Pole olemas ühtset taktikat, mis takistaks kõigi defektide tootmisest välja pääsemist.
Seega on XP lahenduseks komplekteerida kvaliteedinäitajad. Paarprogrammeerimine, testimine, pidev integreerimine. Igaüks üks kaitseliin, koos praktiliselt läbimatu sein.
Rike: ebaõnnestumine ei ole raiskamine, kui see muutub teadmisteks. Tegutsemine ja kiire õppimine selle kohta, mis ei tööta, on paljude valikute hulgast valimisel palju produktiivsem kui otsustamatusest põhjustatud tegevusetus.
qualita: Inimesed arvavad sageli, et kvaliteedi ja kiiruse vahel on dilemma.
See on vastupidi: kvaliteedi parandamise poole püüdlemine paneb sind kiiremini liikuma.
Näiteks refaktoreerimine – koodi struktuuri muutmine selle käitumist muutmata – on tava, mis muudab koodi mõistmise ja muutmise lihtsamaks. Seetõttu on vähem tõenäoline, et tekitate koodidefekte, mis võimaldab teil esmalt pakkuda rohkem väärtust, kuna te ei pea vigu parandama.
Väikesed sammud: Suured muutused on riskantsed. XP vähendab seda riski, tehes muudatusi väikeste sammude kaupa igal tasandil.
Programmeerijad kirjutavad koodi väikeste sammudega, kasutades testipõhist arendust. Nad integreerivad oma koodi põhiliini mitu korda päevas, mitte iga paari nädala või isegi kuu tagant. Projekt ise toimub pigem lühikeste tsüklitena kui pikaajalistena.
Vastutus võetud: XP-s tuleks vastutust aktsepteerida, mitte kunagi määrata.
Vastutusega peaks kaasnema volitus teha otsuseid selle kohta, mille eest vastutate. Tõsi on ka vastupidine. Sa ei taha, et inimesed teeksid otsuseid, kui nad ei pea nende tagajärgedega elama.
Extreme programmeerimise kui agiilse metoodikaga saab nõustuda ja seda kasutusele võtta ilma jäikade plaanideta. See on pigem iteratiivne kujundus kui suur algprojekt.
XP erineb oluliselt traditsioonilistest metoodikatest ehk kaskaadist, vältides pikaajalisi faase.
Mille poolest XP erineb teistest agiilsetest metoodikatest?
Ekstreemprogrammeerimisel on oma olemuselt palju ühist teiste agiilsete metoodikatega, kuid see on ka nende seas ainulaadne.
Enamik teisi arendusmetoodikaid ei ütle palju, kui üldse, selle kohta, kuidas tööd teha. XP seevastu on selles osas väga arvamuslik ja paneb suurt rõhku tarkvaratehnoloogia tavadele.
Scrum on raamistik, mis aitab meeskondadel arendada keerulisi projekte adaptiivsel viisil. Scrum ei määra, kuidas arendajad oma tööd teevad. XP, nagu mainitud, paneb suurt rõhku headele programmeerimistavadele.
Koostamine BlogInnovazione.et Pilt võrgulahendused
Samuti on XP ilmselgelt programmeerimine. Scrum seevastu saab rakendada iga projekti puhul, mis saab kasu iteratiivsest lähenemisest.
XP aktsepteerib selle komponentide muudatusi. Meeskonnad on volitatud ja isegi julgustatud muutma tavasid vastavalt nende konkreetsetele vajadustele. Scrum Guide seevastu on veendunud, et "Kuigi ainult Scrumi osasid saab rakendada, pole tulemuseks Scrum."
Samuti on Scrum raamistik, mida tuleb töö tegemiseks täiendada metoodikate ja tavadega.
See tähendab, et äärmusliku programmeerimise ja Scrumiga töötamine on väga soovitatav.
Kent Becki sõnul ei peaks küps XP-meeskond määrama jäikaid rolle, vaid tunnistama, et rollid võivad olla kasulikud algavatele meeskondadele, kuni nad hakkavad aeglustuma või muudavad koostöö keeruliseks.
Vaatame mõnda võtmerolli:
Need on XP-s kasutusele võetud tavad. Need jagunevad kolme põhirühma: tarkvaratehnika, töökoha ja projektijuhtimine.
Paari programmeerimine: XP-s kirjutate koodi paarikaupa masinal istudes. Teie ja teie paar räägite üksteisega, kui analüüsite, rakendate ja testite funktsiooni, mille kallal töötate. Paariprogrammeerimine on eriti hea vähemate vigadega koodi loomisel, olles samas kaasahaarav, lõbus ja väsitav.
Kümne minuti piirang: Nõutav Võimaldab kogu projekti ülesehitamiseks 10 minutit, sealhulgas kõigi automatiseeritud testide käivitamiseks, maksimaalselt kümne minutiga. See piirang on selleks, et testimine oleks sujuvam ja tõhus.
Testid enne programmeerimist: rakendage funktsioone, kasutades meetodit "test-first", mida nimetatakse ka testipõhine arendus (TDD). TDD koosneb arendusest, kasutades lihtsat iteratiivset protseduuri:
TDD-l on mitmeid eeliseid.
Esiteks tagasiside. Kui testi koostamine on keeruline, on otsitav või päritud kujundus tõenäoliselt liiga keeruline ja peate seda lihtsustama.
Teiseks võimaldab TDD programmeerijatel usaldada nende kirjutatud koodi ja loob mõnusa silmusrütmi, kus järgmine samm on alati selge.
Viimaseks, kuid mitte vähem tähtsaks, tagab TDD kasutamine algusest peale 100% koodikatvuse. Testkomplektist saab siis tõeliselt turvavõrk tulevaste muudatuste jaoks, soodustades koodide ümberkujundamist ja luues positiivse kvaliteediringi.
Inkrementaalne disain: Inkrementaalse disaini praktika tähendab, et peate iga päev investeerima oma rakenduste kujundusse, otsides võimalusi dubleerimise eemaldamiseks ja väikeste täiustuste tegemiseks, et saavutada parim võimalik kujundus teie süsteemi jaoks praeguste vajaduste jaoks.
Pidev integreerimine: XP-s integreerite oma töö mitu korda päevas peamisse jagatud hoidlasse, käivitades kogu süsteemi automaatse ehitamise. Integreerimine võimalikult varakult ja nii sageli vähendab integreerimise kulusid järsult, kuna vähendab liitumiste ja loogiliste konfliktide tekkimist. See paljastab ka keskkonna- ja sõltuvusprobleemid.
Jagatud kood (kollektiivne omand): XP reklaamib jagatud koodi või kollektiivset omandit: iga arendaja vastutab kogu koodi eest. See soodustab teabevahetust, vähendab meeskonna siini tegurit ja tõstab iga mooduli üldist kvaliteeti, kui arvestada mitmekesisuse põhimõtet.
Üks CodeBase: Ühtset koodibaasi tuntakse ka kui "pagasiruumipõhist arendust". See tähendab, et tõe allikas on ainult üks. Nii et selle asemel, et areneda pikka aega isolatsioonis, ühendage oma panused varakult ja sageli ühte voogu. Funktsioonide lipud aitavad piirata funktsioonide kasutamist, kuni need on lõpetatud.
Igapäevane jaotus: tootmises juurutamine vähemalt kord päevas on pideva integreerimise loogiline tagajärg:. Tegelikult lähevad paljud meeskonnad tänapäeval veelgi kaugemale ja harjutavad pidevat rakendamist. See tähendab, et kui keegi liitub põhiliiniga, juurutatakse rakendus tootmisse.
Kood ja testid: See tava tähendab, et lähtekood, sealhulgas testid, on tarkvaraprojekti ainus püsiv artefakt. Teist tüüpi artefaktide, sealhulgas dokumentatsiooni loomisega tegelemine on sageli raiskav, kuna see ei loo kliendi jaoks tegelikku väärtust.
Kui vajate muid artefakte või dokumente, proovige neid tootmiskoodi ja testide põhjal luua.
Algpõhjuse analüüs: Kui defekt läheb tootmisse, ärge lihtsalt parandage defekti. Veenduge, et mõistaksite, mis selle üldse põhjustas, miks teie ja teie meeskonnakaaslased ei suutnud libisemist ära hoida. Seejärel astuge samme, et see ei korduks.
Istuge koos: XP-s eelistavad meeskonnad töötada koos avatud ruumis. See praktika soodustab suhtlemist ja meeskonda kuulumise tunnet.
Kogu meeskond: XP tiimi kuuluvad kõik, keda projekti õnnestumiseks vaja on. See on väga kontekstuaalne – iga meeskonna puhul erinev – ja dünaamiline, see võib meeskonna sees muutuda.
Teabe tööruumid: teabetööruum kasutab meeskonna füüsilist ruumi, et kuvada teavet, mis võimaldab kõigil projekti edenemisest lühidalt teada saada. Kuidas seda tehakse, võib see erineda, alates füüsilistest märkmetest ja graafikutest kuni ekraanipiltideni, mis näitavad projektihaldustarkvarast pärit Kanbani tahvleid ja armatuurlaudu.
Energiline töö: XP-s töötate ainult seni, kuni saate teha energilist tööd. Tööaeg peab olema piiratud 40 tunniga nädalas, maksimaalselt.
ANALISI- Kirjutage kasutaja nõuded vormingus, mida nimetatakse kasutajaanalüüsiks. Kasutajaanalüüsil on lühike kirjeldav nimi ja ka lühike kirjeldus selle kohta, mida on vaja rakendada.
Lõtv: Tsükli planeerimisel lisa väiksemaid ülesandeid, millest meeskond võib vajaduse korral loobuda. Lugusid saab alati juurde lisada, kui meeskond liiga palju toimetab.
Tsüklid (igakuised ja nädalased): XP arendus toimub kahes põhitsüklis: nädala tsükkel ja kuutsükkel.
Koosolekud, tsüklid, plaanitud väljaanded: XP arendus töötab kahes põhitsüklis: nädala tsükkel ja kvartalitsükkel. Algselt soovitas Kent Beck kahenädalast tsüklit, kuid muutis seda oma raamatu teises väljaandes.
Iganädalane tsükkel: iganädalane tsükkel on XP projekti "pulss". Tsükkel algab koosolekuga, kus klient valib, milliseid lugusid ta soovib nädala jooksul luua. Lisaks vaatab meeskond oma tööd, sealhulgas eelmise nädala edusamme, ja mõtleb, kuidas oma protsessi parandada.
Igakuine tsükkel: Iga kuu kajastab meeskond oma protsessis parendusvõimalusi ja teeb need kindlaks. Klient valib selleks kuuks ühe või mitu teemat koos nende teemade analüüsidega.
Kuidas alustada tööd ekstreemse programmeerimisega?
Tehnilisi oskusi ja XP-harjumusi võib olla raske õppida. Mõned tavad võivad tunduda võõrad programmeerijatele, kes pole nendega harjunud.
Ercole Palmeri
Catania polikliinikus viidi läbi oftalmoplastika operatsioon Apple Vision Pro reklaamivaaturiga…
Peenmotoorika arendamine värvimise kaudu valmistab lapsi ette keerukamate oskuste, nagu kirjutamise, jaoks. Värvimiseks…
Meresõidusektor on tõeline ülemaailmne majanduslik jõud, mis on liikunud 150 miljardi suuruse turu poole...
Eelmisel esmaspäeval teatas Financial Times tehingust OpenAI-ga. FT litsentsib oma maailmatasemel ajakirjandust…
