Vi konas programadon, sed Ekstrema Programado (mallonge XP) estas ankoraŭ iom mistero por vi.
Ne lasu la nomon forpuŝi vin, vi riskas maltrafi utilajn informojn.
En ĉi tiu artikolo, ni kovros ĉion, kion vi bezonas scii pri Ekstrema Programado, por ke vi povu uzi ĝin al via avantaĝo.
Ekstrema programado estas softvarmetodaro kiu estas parto de kio estas kolektive konata kiel lertaj metodaroj. XP estas konstruita sur valoroj, principoj kaj praktikoj, kaj ĝia celo estas ebligi al malgrandaj kaj mezgrandaj teamoj produkti altkvalitan programaron kaj adaptiĝi al ĉiam ŝanĝantaj kaj evoluantaj postuloj.
Kio distingas XP de aliaj lertaj metodaroj estas, ke XP emfazas la teknikajn aspektojn de programaro. Ekstrema programado estas preciza pri kiel inĝenieroj funkcias, ĉar sekvado de inĝenieraj praktikoj permesas al teamoj liveri altkvalitan kodon je daŭrigebla rapideco.
Ekstrema programado estas, resume, bonaj praktikoj prenitaj al ekstremo. Ĉar parprogramado estas bona, ni faru ĝin la tutan tempon. Ĉar testado anticipe estas bona, ni testas antaŭ ol produktkodo eĉ estas skribita.
XP, male al aliaj metodaroj, baziĝas sur valoroj kaj principoj gravaj kaj gravaj laŭ inĝenieraj praktikoj.
Valoroj donas celon al teamoj. Ili agas kiel "norda stelo" por gvidi viajn decidojn je alta nivelo. Tamen, la valoroj estas abstraktaj kaj tro malklaraj por specifa gvidado. Ekzemple: Diri, ke vi taksas komunikadon, povas konduki al multaj malsamaj rezultoj.
Praktikoj estas, iusence, la malo de valoroj. Ili estas konkretaj kaj sur la tero, defifiksante la specifaĵoj de kion fari. Praktikoj helpas teamojn teni sin respondecaj pri valoroj. Ekzemple, la praktiko de informaj laborspacoj promocias travideblan kaj simplan komunikadon.
Principoj estas domajno-specifaj gvidlinioj kiuj transpontas la interspacon inter praktikoj kaj valoroj.
XP-valoroj: komunikado, simpleco, retrosciigo, kuraĝo kaj respekto. Ni rigardu ĉiun el ili pli detale.
redakcio BlogInnovazione.ĝi de la bildo alexsoft.com
komunikado: Manko de komunikado malhelpas scion flui ene de teamo. Ofte, kiam estas problemo, iu jam scias kiel ripari ĝin. Sed manko de komunikado malhelpas ilin lerni pri la problemo aŭ kontribui al ĝia solvo. Tiel, la problemo finas esti solvita dufoje, generante malŝparon.
Simpleco: Simpleco diras, ke vi ĉiam strebas fari la plej simplan aferon, kiu funkcias. Ĝi estas ofte miskomprenita kaj konsiderata kiel la plej simpla afero, punkto, ignorante la parton "tio funkcias".
Ankaŭ estas esenca memori, ke simpleco estas tre kunteksta. Kio estas simpla por unu teamo, estas kompleksa por alia kaj dependas tute de la kapabloj, sperto kaj scio de ĉiu teamo.
sugestoj: Reago en pli tradiciaj, kaskadaj softvarmetodaroj ofte estas "tro malmulte, tro malfrue".
XP, tamen, ampleksas ŝanĝon kaj XP-teamoj strebas por ĝustatempa kaj konstanta retrosciigo. Se necesas kurskorekto, XPers volas scii kiel eble plej baldaŭ.
redakcio BlogInnovazione.ĝi de la bildo alexsoft.com
Reago venas en multaj formoj kaj grandecoj. Kiam vi estas partnera programado, komentoj de via kolego estas esencaj rimarkoj. Tiel estas la opinioj de aliaj teamanoj pri ideo, inkluzive de la kliento kiu, ideale, estas membro de la teamo.
Testoj estas alia fonto de valoraj sugestoj, kiuj iras preter testrezultoj. Ĉu skribi testojn estas facila aŭ malfacila, ankaŭ reagoj. Se vi havas problemojn skribi testojn, via projekto verŝajne estas tro kompleksa. Aŭskultu komentojn kaj simpligu vian dezajnon.
Io kiu sonas kiel bonega ideo eble ne funkcias tiel bone en la praktiko. Tial, finita kodo ankaŭ estas fonto de retrosciigo, same kiel distribuita produkto.
Fine, memoru, ke estas tro da sugestoj. Se teamo generas pli da sugestoj ol ĝi povas manipuli, gravaj sugestoj povus fali de la radaro. Do estas esence malrapidigi kaj eltrovi kio kaŭzas la troan retrosciigon kaj ripari ĝin.
Kuraĝo: Kent Beck defikuraĝo aperas kiel "efika ago antaŭ timo". Kiel programaro-inĝeniero, vi havas multon por timi kaj tial multajn ŝancojn montri kuraĝon.
Necesas kuraĝo diri la veron, precipe la malagrablajn, kiel honestajn taksojn. Doni kaj ricevi reagojn ankaŭ postulas kuraĝon. Kaj necesas kuraĝo por eviti fali en la mallevita kosto-trompo kaj forĵeti malsukcesan solvon, kiu ricevis grandan investon.
Respekto: Fundamenta premiso de XP estas, ke ĉiuj zorgas pri sia laboro. Neniu kvanto da teknika plejboneco povas savi projekton se mankas zorgo kaj respekto.
Ĉiu persono estas inda je digno kaj respekto, kaj tio inkluzivas, kompreneble, la homojn implikitajn en programarprojekto. Kiam vi kaj viaj teamanoj respektas kaj zorgas unu la alian, la kliento, la projekto kaj ĝiaj estontaj uzantoj, ĉiuj profitas
Principoj provizas pli specifan gvidadon ol valoroj. Ili estas gvidlinioj, kiuj lumigas la valorojn kaj faras ilin pli eksplicitaj kaj malpli ambiguaj.
redakcio BlogInnovazione.ĝi de la bildo alexsoft.com
Ekzemple, surbaze de la valoro de kuraĝo sole, vi povus konkludi, ke estas konsilinde fari grandan ŝanĝon en via horaro tuj. Tamen, la principo de Baby Steps diras al ni, ke grandaj ŝanĝoj estas riskaj. Do preferu la malgrandajn anstataŭe.
Homaro: Homoj kreas programaron por homoj, ofte preteratentitan fakton. Sed konsiderante bazajn homajn bezonojn, fortojn kaj malfortojn kreas produktojn, kiujn homoj volas uzi. Kaj labormedio kiu ofertas al vi la ŝancon por plenumi kaj kresko, la sento de aparteno kaj baza sekureco, estas loko kie vi pli facile konsideras la bezonojn de aliaj.
Ekonomio: En XP, teamoj ĉiam atentas la ekonomiajn realaĵojn de programaro, konstante taksas ekonomiajn riskojn kaj projektbezonojn.
Ekzemple, ili efektivigus uzantrakontojn bazitajn sur sia komerca valoro prefere ol teknikaj zorgoj.
Reciproka profito: Post XP, vi evitas solvojn, kiuj profitigas unu partion koste de alia. Ekzemple, plilongigitaj specifoj povus helpi iun alian kompreni ĝin, sed ĝi malatentigas vin de efektivigi ĝin kaj prokrastas ĝin por viaj uzantoj.
Reciproke utila solvo estas uzi aŭtomatajn akceptajn testojn. Ricevu tujajn rimarkojn pri via efektivigo, viaj kunuloj ricevas precizajn specifojn en kodo, kaj uzantoj unue ricevas siajn funkciojn. Krome, vi ĉiuj havos sekurecan reton kontraŭ regresoj.
Profito (Reciproka Profito): Se donita solvo funkcias je unu nivelo, ĝi ankaŭ povas funkcii ĉe pli alta aŭ pli malalta nivelo. Ekzemple, ricevi fruan kaj konstantan reagojn estas en risko diversgrade en XP.
Pliboniĝo: Laŭ la principo de plibonigo, teamoj ne celas perfektecon en komenca efektivigo, sed efektivigon kiu estas sufiĉe bona, kaj poste daŭre lernas kaj plibonigas ĝin kun sugestoj de realaj uzantoj.
Diverseco: Vi kaj viaj kolegoj profitas el diverseco de perspektivoj, kapabloj kaj sintenoj. Tia diverseco ofte kondukas al konflikto, sed tio estas en ordo.
Konflikto kaj malkonsento estas ŝancoj por ke pli bonaj ideoj aperu kiam ĉiuj ludas per la valoroj de kuraĝo kaj respekto. Kuraĝo esprimi kontraŭajn vidpunktojn, respekton esprimi ilin en civila kaj empatia maniero. Kaj ĉio ĉi estas efika komunika ekzerco.
Reflektado: Grandaj teamoj pripensas sian laboron kaj analizas kiel esti pli bonaj. XP ofertas multajn ŝancojn por tio. Ne nur en siaj semajnaj kaj kvaronjaraj cikloj, sed en ĉiu praktiko ĝi antaŭenigas.
Sentoj estas grave konsideri krom logika analizo. Via intesto povas informi vin antaŭ ol vi povas rezoni pri io ajn. Kaj tiel li povas paroli kun neteknikaj homoj, ili povas fari demandojn kiuj malfermas tute novajn eblecojn.
Fluo: Tradiciaj programarmetodaroj havas apartajn fazojn, kiuj daŭras longan tempon kaj havas malmulte da ŝanco por retrosciigo kaj kurskorektado. Anstataŭe, programaro en XP okazas en agadoj kiuj okazas kontinue, en konsekvenca "fluo" de valoro.
Ŝanco: Problemoj estas neeviteblaj en programaro. Tamen ĉiu problemo estas ŝanco por plibonigo. Lernu rigardi ilin tiamaniere kaj vi multe pli verŝajne elpensos kreajn kaj cel-orientitajn solvojn, kiuj ankaŭ servas por malhelpi ilin okazi denove.
Redundo: La principo de redundo diras ke se donita problemo estas kritika, vi devas uzi multajn taktikojn por kontraŭstari ĝin.
Prenu la difektojn. Ne ekzistas ununura taktiko, kiu povas malhelpi ĉiujn difektojn eskapi de produktado.
Do la solvo de XP estas stakigi aron da kvalitaj mezuroj. Parprogramado, testado, kontinua integriĝo. Ĉiu unuopa linio de defendo, kune preskaŭ nepenetrebla muro.
Malsukceso: malsukceso ne estas malŝparo, kiam ĝi tradukiĝas en scion. Agi kaj rapide lerni tion, kio ne funkcias, estas multe pli produktiva ol neagado kaŭzita de nedecidemo elekti inter multaj elektoj.
Kvalito: Homoj ofte pensas, ke estas dilemo inter kvalito kaj rapideco.
Estas inverse: puŝi plibonigi kvaliton estas kio igas vin iri pli rapide.
Ekzemple, refactoring—ŝanĝi la strukturon de kodo sen ŝanĝi ĝian konduton—estas praktiko kiu igas kodon pli facile kompreni kaj ŝanĝi. Kiel rezulto, vi malpli verŝajne enkondukos koddifektojn, kio ebligas al vi liveri pli da valoro unue per ne devi ripari cimojn.
Eta paŝoj: Grandaj ŝanĝoj estas riskaj. XP mildigas tiun riskon farante ŝanĝojn en malgrandaj paŝoj, je ĉiu nivelo.
Programistoj skribas kodon en etaj paŝoj uzante test-movitan evoluon. Ili integras sian kodon en la ĉeftendencon plurfoje tage, anstataŭ nur ĉiujn kelkajn semajnojn aŭ eĉ monatojn. La projekto mem okazas en mallongaj cikloj prefere ol longdaŭraj fazoj.
Respondeco akceptita: En XP, respondeco estu akceptita, neniam asignita.
Respondeco devus veni kun la aŭtoritato fari decidojn pri kio vi respondecas. La malo estas ankaŭ vera. Vi ne volas, ke homoj faru decidojn se ili ne devas vivi kun siaj sekvoj.
Ekstrema programado, estante lerta metodaro, povas esti akceptita kaj komencita adopti ĝin sen sekvi rigidajn planojn. Ĉi tio estas ripeta dezajno prefere ol granda komenca projekto.
XP diferencas signife de tradiciaj metodaroj, t.e. kaskada, evitante longdaŭrajn fazojn.
Kiel XP diferencas de aliaj lertaj metodaroj?
Ekstrema programado, laŭ sia naturo, havas multon en komuna kun aliaj lertaj metodaroj sed ankaŭ estas unika inter ili.
Plej multaj aliaj evoluigaj metodoj ne multe diras, se io ajn, pri kiel fari la laboron. XP, aliflanke, estas tre opiniema kiam temas pri tio kaj metas grandan emfazon sur softvarinĝenieraj praktikoj.
Scrum estas kadro por helpi teamojn evoluigi kompleksajn projektojn en adapta maniero. Scrum ne diktas kiel programistoj faras sian laboron. XP, kiel menciite, multe emfazas bonajn programajn praktikojn.
redakcio BlogInnovazione.eo Bildo retaj solvoj
Ankaŭ, XP evidente temas pri programado. Scrum, aliflanke, povas esti aplikita al ajna projekto kiu profitas de ripeta aliro.
XP akceptas ŝanĝojn al siaj komponantoj. Teamoj estas rajtigitaj kaj eĉ kuraĝigitaj modifi praktikojn laŭ siaj specifaj bezonoj. La Scrum Gvidilo, aliflanke, estas nefleksebla ke "Kvankam nur partoj de Scrum povas esti efektivigitaj, la rezulto ne estas Scrum".
Ankaŭ, Scrum estas kadro, kiu devas esti kompletigita per metodaroj kaj praktikoj por fari la laboron.
Ĉi tio signifas, ke labori en ekstrema programado kaj Scrum estas tre rekomendinda.
Laŭ Kent Beck, matura XP-teamo ne devus asigni rigidajn rolojn, sed rekoni, ke roloj povas esti utilaj por novnaskitaj teamoj ĝis ili komencas malrapidigi aŭ malfaciligi kunlaboron.
Ni rigardu kelkajn ŝlosilajn rolojn:
Ĉi tiuj estas la praktikoj adoptitaj en XP. Ili estas dividitaj en tri ĉefajn grupojn: programaro-inĝenierado, laborejo kaj projekt-administrado.
Parprogramado: En XP, vi skribas kodon duope sidante sur maŝino. Vi kaj via paro parolas unu kun la alia dum vi analizas, efektivigas kaj testas la funkcion pri kiu vi laboras. Parprogramado estas precipe bona por produkti kodon kun malpli da cimoj dum ankoraŭ estas engaĝa, amuza kaj laciga.
Limo de dek minutoj: Bezonata Permesas 10 minutojn por konstrui la tutan projekton, inkluzive de rulado de ĉiuj aŭtomataj testoj, en maksimume dek minutoj. Ĉi tiu limo estas konservi testadon simpligita kaj efika.
Testoj antaŭ programado: efektivigi funkciojn uzante la testo-unua aliro, ankaŭ nomita Test-movita evoluo (TDD). TDD konsistas el evoluo uzanta simplan ripetan proceduron:
TDD alportas plurajn avantaĝojn.
Unue, reagoj. Se estas malfacile skribi teston, la dezajno, kiun vi serĉas aŭ kiun vi heredis, verŝajne estas tro kompleksa kaj vi devas simpligi ĝin.
Due, TDD permesas al programistoj fidi la kodon, kiun ili skribas, kaj kreas belan loopritmon kie la sekva paŝo ĉiam estas klara.
Laste sed ne malpli, uzi TDD de la komenco certigas 100%-kodan kovradon. La testaro tiam vere fariĝas sekureca reto por estontaj ŝanĝoj, kuraĝigante kodon refactoring kaj kreante virtan rondon de kvalito.
Pliiga dezajno: La praktiko de pliiga dezajno signifas, ke vi devas investi en via aplika dezajno ĉiutage, serĉante ŝancojn forigi duobligon kaj fari malgrandajn plibonigojn por atingi la plej bonan eblan dezajnon por tio, kion via sistemo bezonas hodiaŭ.
Daŭra integriĝo: En XP, vi integras vian laboron en la ĉefa komuna deponejo plurfoje tage, ekigante aŭtomatan konstruon de la tuta sistemo. Integriĝo kiel eble plej frue kaj kiel eble draste reduktas la koston de integriĝo ĉar ĝi faras kunfandaĵojn kaj logikaj konfliktoj malpli verŝajne okazi. Ĝi ankaŭ elmontras mediajn kaj toksomaniajn problemojn.
Komuna kodo (kolektiva proprieto): XP antaŭenigas komunan kodon, aŭ kolektivan posedon: ĉiu programisto respondecas pri la tuta kodo. Ĝi instigas informinterŝanĝon, reduktas la teambusfaktoron kaj pliigas la ĝeneralan kvaliton de ĉiu modulo se ni konsideras la principon de diverseco.
Ununura CodeBase: Ununura kodbazo ankaŭ estas konata kiel "trunk-bazita evoluo". Ĝi signifas, ke ekzistas nur unu fonto de vero. Do anstataŭ disvolvi izole dum longaj tempodaŭroj, kunfandu viajn kontribuojn en ununuran fluon frue kaj ofte. Trajtaj flagoj helpas limigi vian uzon de funkcioj ĝis ili finiĝos.
Ĉiutaga distribuo: deplojo en produktado almenaŭ unufoje tage estas logika sekvo de kontinua integriĝo:. Fakte, hodiaŭ multaj teamoj iras eĉ pli for kaj praktikas kontinuan efektivigon. Tio estas, kiam ajn iu aliĝas al la ĉeftendenca, la aplikaĵo estas deplojita al produktado.
Kodo kaj provoj: Ĉi tiu praktiko signifas, ke fontkodo, inkluzive de testoj, estas la nura konstanta artefakto de programara projekto. Engaĝiĝi en la generacio de aliaj specoj de artefaktoj, inkluzive de dokumentado, ofte estas malŝparema ĉar ĝi ne generas realan valoron por la kliento.
Se vi bezonas aliajn artefaktojn aŭ dokumentojn, penu generi ilin el produktadkodo kaj testoj.
Analizo de radika kaŭzo: Kiam ajn difekto eniras en produktadon, ne nur korektu la difekton. Certigu, ke vi unue eltrovas, kio kaŭzis ĝin, kial vi kaj viaj samteamanoj malsukcesis malhelpi la glitiĝon. Poste, faru paŝojn por certigi, ke ĝi ne okazos denove.
Sidu kune: En XP, teamoj preferas labori kune en malferma spaco. Ĉi tiu praktiko antaŭenigas komunikadon kaj senton de aparteno al teamo.
La tuta teamo: Ĉiuj, kiuj estas bezonataj por la sukceso de la projekto, estas parto de la XP-teamo. Ĉi tio estas tre kunteksta - malsama por ĉiu teamo - kaj dinamika, ĝi povas ŝanĝiĝi ene de teamo.
Informaj laborspacoj: informa laborspaco uzas la fizikan spacon de la teamo por montri informojn, kiuj ebligas al iu ajn scii, per unu ekrigardo, la progreson de la projekto. Kiel ĉi tio estas farita povas varii, de fizikaj notoj kaj grafikaĵoj ĝis ekrankopioj montrantaj Kanban-tabulojn kaj instrumentpanelojn de projekt-administrada programaro.
Energigita laboro: En XP, vi laboras nur tiom longe kiom vi povas fari energian laboron. Laborhoroj devas esti limigitaj al 40 semajne, maksimume.
Analisi- Skribu uzantpostulojn en formato konata kiel uzantanalizo. Uzantanalizo havas mallongan, priskriban nomon kaj ankaŭ mallongan priskribon de kio devas esti efektivigita.
slack: Planante ciklon, aldonu negravajn taskojn, kiujn la teamo povas forlasi se la bezono ekestas. Pli da rakontoj ĉiam povas esti aldonitaj se la teamo liveras tro multe.
Cikloj (monataj kaj semajnaj): Evoluo en XP okazas en du ĉefaj cikloj: la semajna ciklo kaj la monata ciklo.
Renkontiĝoj, cikloj, planitaj eldonoj: Evoluo en XP funkcias en du ĉefaj cikloj: la semajna ciklo kaj la kvaronjara ciklo. Komence, Kent Beck rekomendis du-semajnan ciklon, sed ŝanĝis tion en la dua eldono de sia libro.
Semajna ciklo: la semajna ciklo estas la "pulso" de XP-projekto. La ciklo komenciĝas per renkontiĝo en kiu la kliento elektas kiujn rakontojn li volas krei dum la semajno. Aldone, la teamo recenzas sian laboron, inkluzive de la progreso de la pasinta semajno, kaj pensas pri manieroj plibonigi sian procezon.
Monata ciklo: Ĉiumonate, la teamo pripensas kaj identigas plibonigeblecojn en sia procezo. La kliento elektas unu aŭ plurajn temojn por tiu monato, kune kun la analizoj en ĉi tiuj temoj.
Kiel komenci labori kun ekstrema programado?
Teknikaj kapabloj kaj XP-kutimoj povas esti malfacile lerneblaj. Kelkaj el la praktikoj povas ŝajni fremdaj al programistoj ne kutimaj al ili.
Ercole Palmeri
Pasintlunde, la Financial Times anoncis interkonsenton kun OpenAI. FT licencas sian mondklasan ĵurnalismon...
Milionoj da homoj pagas por streaming-servoj, pagante monatajn abonkotizojn. Estas komuna opinio, ke vi...
Coveware de Veeam daŭre liveros servojn de respondaj incidentoj pri ciberĉantaĝo. Coveware ofertos krimmedicinajn kaj solvajn kapablojn...
Prognoza prizorgado revolucias la petrolon kaj gasan sektoron, kun noviga kaj iniciatema aliro al plantadministrado...
