Infrastruktura si kod: si të kapërceni problemet duke përdorur XP

Përshëndetje, Habr! Më parë jam ankuar për jetën në Infrastrukturë si paradigmë kodike dhe nuk kam ofruar asgjë për zgjidhjen e situatës aktuale. Sot jam kthyer për t'ju treguar se cilat qasje dhe praktika do t'ju ndihmojnë të shpëtoni nga humnera e dëshpërimit dhe ta drejtoni situatën në drejtimin e duhur.

Në një artikull të mëparshëm "Infrastruktura si kod: njohja e parë" Unë ndava përshtypjet e mia për këtë fushë, u përpoqa të reflektoja mbi situatën aktuale në këtë fushë dhe madje sugjerova që praktikat standarde të njohura për të gjithë zhvilluesit mund të ndihmojnë. Mund të duket se ka pasur shumë ankesa për jetën, por nuk ka pasur propozime për një rrugëdalje nga situata aktuale.

Kush jemi, ku jemi dhe çfarë problemesh kemi

Aktualisht jemi në ekipin e Sre Onboarding, i cili përbëhet nga gjashtë programues dhe tre inxhinierë të infrastrukturës. Të gjithë po përpiqemi të shkruajmë Infrastrukturën si kod (IaC). Ne e bëjmë këtë sepse ne në thelb dimë të shkruajmë kod dhe kemi një histori të të qenit zhvillues "mbi mesataren".

• Ne kemi një sërë avantazhesh: një sfond të caktuar, njohuri për praktikat, aftësinë për të shkruar kode, një dëshirë për të mësuar gjëra të reja.
• Dhe ka një pjesë të zbehtë, e cila është gjithashtu një minus: mungesa e njohurive për pajisjet e infrastrukturës.

Skema e teknologjisë që përdorim në IaC tonë.

• Terraformë për krijimin e burimeve.
• Paketues për montimin e imazheve. Këto janë imazhe të Windows, CentOS 7.
• Jsonnet për të bërë një ndërtim të fuqishëm në drone.io, si dhe për të gjeneruar paketues json dhe modulet tona terraform.
• Azure
• E përgjegjshme gjatë përgatitjes së imazheve.
• Python për shërbime ndihmëse dhe skriptet e sigurimit.
• Dhe e gjithë kjo në VSCode me shtojca të ndara midis anëtarëve të ekipit.

Konkluzioni nga imja artikulli i fundit ishte kështu: u përpoqa të rrënjos (para së gjithash tek vetja) optimizmin, doja të them se do të provojmë qasjet dhe praktikat e njohura për të përballuar vështirësitë dhe kompleksitetet që ekzistojnë në këtë fushë.

Aktualisht po luftojmë me çështjet e mëposhtme të IaC:

• Papërsosmëria e mjeteve dhe mjeteve për zhvillimin e kodit.
• Vendosja e ngadaltë. Infrastruktura është pjesë e botës reale dhe mund të jetë e ngadaltë.
• Mungesa e qasjeve dhe praktikave.
• Ne jemi të rinj dhe nuk dimë shumë.

Programimi ekstrem (XP) në shpëtim

Të gjithë zhvilluesit janë të njohur me Extreme Programming (XP) dhe praktikat që qëndrojnë pas tij. Shumë prej nesh kanë punuar me këtë qasje, dhe ajo ka qenë e suksesshme. Pra, pse të mos përdorni parimet dhe praktikat e përcaktuara atje për të kapërcyer sfidat e infrastrukturës? Ne vendosëm të marrim këtë qasje dhe të shohim se çfarë ndodh.

Kontrollimi i zbatueshmërisë së qasjes XP në industrinë tuajKëtu është një përshkrim i mjedisit për të cilin XP është i përshtatshëm dhe se si ai lidhet me ne:

1. Kërkesat e softuerit ndryshojnë në mënyrë dinamike. Ishte e qartë për ne se cili ishte qëllimi përfundimtar. Por detajet mund të ndryshojnë. Ne vetë vendosim se ku duhet të transportojmë taksi, kështu që kërkesat ndryshojnë periodikisht (kryesisht vetë). Nëse marrim ekipin SRE, i cili bën vetë automatizimin, dhe vetë kufizon kërkesat dhe fushëveprimin e punës, atëherë kjo pikë përshtatet mirë.

2. Rreziqet e shkaktuara nga projektet me kohë fikse duke përdorur teknologji të re. Mund të hasim rreziqe kur përdorim disa gjëra të panjohura për ne. Dhe ky është 100% rasti ynë. I gjithë projekti ynë ishte përdorimi i teknologjive që ne nuk i njihnim plotësisht. Në përgjithësi, ky është një problem i vazhdueshëm, sepse... Ka shumë teknologji të reja që shfaqen në sektorin e infrastrukturës gjatë gjithë kohës.

3,4. Ekipi i vogël, i bashkëvendosur i zhvillimit të zgjeruar. Teknologjia e automatizuar që po përdorni ju lejon të testoni njësi dhe funksionale. Këto dy pika nuk na përshtaten aspak. Së pari, ne nuk jemi një ekip i koordinuar dhe së dyti, jemi nëntë veta, të cilët mund të konsiderohen një ekip i madh. Megjithëse, sipas disa përkufizimeve të një ekipi "të madh", shumë janë 14+ persona.

Le të shohim disa praktika XP dhe se si ato ndikojnë në shpejtësinë dhe cilësinë e reagimeve.

Parimi i ciklit të reagimit XP

Në kuptimin tim, reagimet janë përgjigjja e pyetjes, a po bëj gjënë e duhur, a do të shkojmë atje? XP ka një skemë hyjnore për këtë: një lak reagimi kohor. Gjëja interesante është se sa më poshtë jemi, aq më shpejt jemi në gjendje të marrim OS për t'iu përgjigjur pyetjeve të nevojshme.

Kjo është një temë mjaft interesante për diskutim, se në industrinë tonë të TI-së është e mundur të merrni shpejt një OS. Imagjinoni sa e dhimbshme është të bësh një projekt për gjashtë muaj dhe vetëm atëherë të zbulosh se ka pasur një gabim që në fillim. Kjo ndodh në projektim dhe në çdo ndërtim të sistemeve komplekse.

Në rastin tonë të IaC, reagimet na ndihmojnë. Do të bëj menjëherë një rregullim të vogël në diagramin e mësipërm: plani i lëshimit nuk ka një cikël mujor, por ndodh disa herë në ditë. Ka disa praktika të lidhura me këtë cikël të OS që do t'i shikojmë më në detaje.

E rëndësishme: reagimet mund të jenë një zgjidhje për të gjitha problemet e përmendura më sipër. Kombinuar me praktikat XP, mund t'ju nxjerrë nga humnera e dëshpërimit.

Si ta tërhiqni veten nga humnera e dëshpërimit: tre praktika

testet

Testet përmenden dy herë në ciklin e reagimit XP. Nuk është vetëm kështu. Ato janë jashtëzakonisht të rëndësishme për të gjithë teknikën e Programimit Ekstrem.

Supozohet se keni teste të njësisë dhe pranimit. Disa ju japin reagime në pak minuta, të tjera në pak ditë, kështu që ata kërkojnë më shumë kohë për t'u shkruar dhe rishikohen më rrallë.

Ekziston një piramidë klasike testimi, e cila tregon se duhet të ketë më shumë teste.

Si zbatohet kjo kornizë për ne në një projekt IaC? Në fakt... aspak.

• Testet e njësisë, përkundër faktit se duhet të ketë shumë, nuk mund të jenë shumë. Ose ata po testojnë diçka në mënyrë shumë indirekte. Në fakt mund të themi se nuk i shkruajmë fare. Por këtu janë disa aplikacione për teste të tilla që ne mundëm t'i bënim:
  1. Testimi i kodit jsonnet. Ky, për shembull, është tubacioni ynë i montimit të dronëve, i cili është mjaft i ndërlikuar. Kodi jsonnet është i mbuluar mirë nga testet.
     Ne e përdorim këtë Korniza e testimit të njësisë për Jsonnet.
  2. Testet për skriptet që ekzekutohen kur burimi fillon. Skriptet shkruhen në Python, dhe për këtë arsye testet mund të shkruhen në to.
• Është potencialisht e mundur të kontrollohet konfigurimi në teste, por ne nuk e bëjmë këtë. Është gjithashtu e mundur të konfiguroni rregullat e konfigurimit të burimeve të kontrollit nëpërmjet stralli. Sidoqoftë, kontrollet atje janë thjesht shumë themelore për terraform, por shumë skripta testimi janë shkruar për AWS. Dhe ne jemi në Azure, kështu që kjo përsëri nuk vlen.
• Testet e integrimit të komponentëve: varet nga mënyra se si i klasifikoni dhe ku i vendosni. Por në thelb funksionojnë.

  Kështu duken testet e integrimit.

  
  
  Ky është një shembull kur ndërtoni imazhe në Drone CI. Për t'i arritur ato, duhet të prisni 30 minuta që të formohet imazhi i Packer, më pas të prisni 15 minuta të tjera që të kalojnë. Por ato ekzistojnë!

  Algoritmi i verifikimit të imazhit

  1. Paketuesi duhet së pari të përgatisë plotësisht imazhin.
  2. Pranë testit ka një terraform me një gjendje lokale, të cilën e përdorim për të vendosur këtë imazh.
  3. Kur shpaloset, përdoret një modul i vogël që ndodhet afër për ta bërë më të lehtë punën me imazhin.
  4. Pasi VM të vendoset nga imazhi, kontrollet mund të fillojnë. Në thelb, kontrollet kryhen me makinë. Ai kontrollon se si funksionuan skriptet në fillim dhe si funksionojnë demonët. Për ta bërë këtë, nëpërmjet ssh ose winrm ne hyjmë në makinën e sapo ngritur dhe kontrollojmë statusin e konfigurimit ose nëse shërbimet janë në funksion.

• Situata është e ngjashme me testet e integrimit në modulet për terraform. Këtu është një tabelë e shkurtër që shpjegon veçoritë e testeve të tilla.

  
  
  Kohëzgjatja e reagimit për tubacionin është rreth 40 minuta. Gjithçka ndodh për një kohë shumë të gjatë. Mund të përdoret për regresion, por për zhvillim të ri në përgjithësi është jorealiste. Nëse jeni shumë, shumë të përgatitur për këtë, përgatitni skriptet e ekzekutimit, atëherë mund ta zvogëloni atë në 10 minuta. Por këto nuk janë ende teste Unit, të cilat bëjnë 5 copë në 100 sekonda.

Mungesa e testeve të njësisë gjatë montimit të imazheve ose moduleve terraforme inkurajon zhvendosjen e punës në shërbime të veçanta që thjesht mund të ekzekutohen nëpërmjet REST, ose në skriptet Python.

Për shembull, na duhej të siguroheshim që kur makina virtuale niset, ajo regjistrohet vetë në shërbim ScaleFT, dhe kur makina virtuale u shkatërrua, ajo u fshi vetë.

Meqenëse ne kemi ScaleFT si shërbim, ne jemi të detyruar të punojmë me të përmes API-së. Aty ishte shkruar një mbështjellës që mund ta tërhiqje dhe të thuash: "Hyni dhe fshini këtë dhe atë". Ai ruan të gjitha cilësimet dhe akseset e nevojshme.

Tashmë mund të shkruajmë teste normale për këtë, pasi nuk ndryshon nga softueri i zakonshëm: një lloj apiha tallen, ju e tërhiqni dhe shikoni se çfarë ndodh.

Rezultatet e testeve: Testimi i njësisë, i cili duhet të japë OS në një minutë, nuk e jep atë. Dhe llojet e testimeve më të larta në piramidë janë efektive, por mbulojnë vetëm një pjesë të problemeve.

Programimi në çift

Testet janë, natyrisht, të mira. Mund të shkruani shumë prej tyre, mund të jenë të llojeve të ndryshme. Ata do të punojnë në nivelet e tyre dhe do të na japin reagime. Por problemi me testet e këqija të Unit, të cilat japin OS më të shpejtë, mbetet. Në të njëjtën kohë, unë dua ende një OS të shpejtë që është i lehtë dhe i këndshëm për të punuar me të. Për të mos përmendur cilësinë e zgjidhjes që rezulton. Për fat të mirë, ka teknika që mund të japin reagime edhe më të shpejta sesa testet e njësisë. Ky është programimi në çift.

Kur shkruani kodin, dëshironi të merrni komente për cilësinë e tij sa më shpejt që të jetë e mundur. Po, mund të shkruani gjithçka në një degë funksionesh (në mënyrë që të mos prishni asgjë për askënd), të bëni një kërkesë tërheqjeje në Github, t'ia caktoni dikujt mendimi i të cilit ka peshë dhe të prisni një përgjigje.

Por mund të prisni një kohë të gjatë. Njerëzit janë të gjithë të zënë dhe përgjigja, edhe nëse ka një të tillë, mund të mos jetë e cilësisë më të lartë. Supozoni se përgjigja erdhi menjëherë, recensuesi e kuptoi menjëherë të gjithë idenë, por përgjigja vjen ende me vonesë, pas faktit. Do të doja të ishte më herët. Kjo është ajo që synon programimi në çift - menjëherë, në kohën e shkrimit.

Më poshtë janë stilet e programimit të çifteve dhe zbatueshmëria e tyre në punën në IaC:

1. Klasik, me përvojë+me përvojë, zhvendosje sipas kohëmatësit. Dy role - shofer dhe navigator. Dy njerez. Ata punojnë në të njëjtin kod dhe ndërrojnë role pas një periudhe të caktuar kohe të paracaktuar.

Le të shqyrtojmë përputhshmërinë e problemeve tona me stilin:

• Problemi: papërsosmëria e mjeteve dhe mjeteve për zhvillimin e kodit.
  Ndikimi negativ: duhet më shumë kohë për t'u zhvilluar, ne ngadalësojmë, ritmi/ritmi i punës humbet.
  Si luftojmë: përdorim një vegël tjetër, një IDE të përbashkët dhe gjithashtu mësojmë shkurtore.
• Problemi: Vendosja e ngadaltë.
  Ndikimi negativ: rrit kohën që duhet për të krijuar një pjesë të kodit të punës. Ne mërzitemi duke pritur, duart tona zgjasin për të bërë diçka tjetër ndërsa presim.
  Si luftojmë: nuk e kapërcejmë.
• Problemi: mungesa e qasjeve dhe praktikave.
  Ndikimi negativ: nuk ka njohuri se si të bëhet mirë dhe si të bëhet keq. Zgjat marrjen e komenteve.
  Si luftojmë: shkëmbimi i ndërsjellë i mendimeve dhe praktikave në punën në çift pothuajse e zgjidh problemin.

Problemi kryesor me përdorimin e këtij stili në IaC është ritmi i pabarabartë i punës. Në zhvillimin tradicional të softuerit, ju keni një lëvizje shumë uniforme. Mund të kaloni pesë minuta dhe të shkruani N. Kaloni 10 minuta dhe shkruani 2N, 15 minuta - 3N. Këtu mund të kaloni pesë minuta dhe të shkruani N, dhe pastaj të kaloni 30 minuta të tjera dhe të shkruani një të dhjetën e N. Këtu nuk dini asgjë, jeni të ngecur, budalla. Hetimi kërkon kohë dhe largon vëmendjen nga vetë programimi.

Përfundim: në formën e tij të pastër nuk është i përshtatshëm për ne.

2. Ping-pong. Kjo qasje përfshin një person që shkruan testin dhe një tjetër bën zbatimin për të. Duke marrë parasysh faktin se gjithçka është e ndërlikuar me testet e Unit dhe duhet të shkruani një test integrimi që kërkon shumë kohë për t'u programuar, e gjithë lehtësia e ping-pongut ikën.

Mund të them se u përpoqëm të ndajmë përgjegjësitë për hartimin e një skripti testimi dhe zbatimin e kodit për të. Një pjesëmarrës doli me skenarin, në këtë pjesë të punës ai ishte përgjegjës, ai kishte fjalën e fundit. Dhe tjetri ishte përgjegjës për zbatimin. Doli mirë. Cilësia e skenarit me këtë qasje rritet.

Përfundim: mjerisht, ritmi i punës nuk lejon përdorimin e ping-pongut si një praktikë programimi në çift në IaC.

3.Stil i fortë. Praktikë e vështirë. Ideja është që një pjesëmarrës të bëhet naviguesi i direktivave dhe i dyti të marrë rolin e drejtuesit të ekzekutimit. Në këtë rast, e drejta për të marrë vendime i takon ekskluzivisht navigatorit. Drejtuesi printon vetëm dhe mund të ndikojë në atë që po ndodh me një fjalë. Rolet nuk ndryshojnë për një kohë të gjatë.

E mirë për të mësuar, por kërkon aftësi të forta të buta. Këtu u lëkundëm. Teknika ishte e vështirë. Dhe nuk bëhet fjalë as për infrastrukturën.

Përfundim: potencialisht mund të përdoret, ne nuk po heqim dorë nga përpjekjet.

4. Mobbing, swarming dhe të gjitha stilet e njohura por jo të listuara Ne nuk e konsiderojmë atë, sepse Ne nuk e kemi provuar dhe është e pamundur të flasim për të në kontekstin e punës sonë.

Rezultatet e përgjithshme për përdorimin e programimit në çift:

• Kemi një ritëm të pabarabartë pune, që është konfuze.
• Ne hasëm në aftësi të buta jo mjaftueshëm të mira. Dhe fusha lëndore nuk ndihmon në tejkalimin e këtyre mangësive tona.
• Testet e gjata dhe problemet me mjetet e bëjnë të vështirë zhvillimin e çifteve.

5. Pavarësisht kësaj, pati suksese. Ne dolëm me metodën tonë "Konvergjenca - Divergjenca". Unë do të përshkruaj shkurtimisht se si funksionon.

Ne kemi partnerë të përhershëm për disa ditë (më pak se një javë). Ne bëjmë një detyrë së bashku. Ne ulemi së bashku për një kohë: njëri shkruan, tjetri ulet dhe shikon ekipin mbështetës. Pastaj shpërndahemi për ca kohë, secili bën disa gjëra të pavarura, pastaj bashkohemi përsëri, sinkronizojmë shumë shpejt, bëjmë diçka së bashku dhe shpërndahemi përsëri.

Planifikimi dhe komunikimi

Blloku i fundit i praktikave përmes të cilit zgjidhen problemet e OS është organizimi i punës me vetë detyrat. Kjo përfshin gjithashtu shkëmbimin e përvojës që është jashtë punës në çift. Le të shohim tre praktika:

1. Objektivat përmes pemës së qëllimit. Ne organizuam menaxhimin e përgjithshëm të projektit përmes një peme që shkon pafund në të ardhmen. Teknikisht gjurmimi bëhet në Miro. Ka një detyrë - është një qëllim i ndërmjetëm. Prej tij shkojnë ose qëllime më të vogla ose grupe detyrash. Vetë detyrat vijnë prej tyre. Të gjitha detyrat krijohen dhe mirëmbahen në këtë tabelë.

Kjo skemë ofron edhe reagime, të cilat ndodhin një herë në ditë kur sinkronizojmë në mitingje. Të kesh një plan të përbashkët para të gjithëve, por të strukturuar dhe plotësisht të hapur, i lejon të gjithëve të jenë të vetëdijshëm për atë që po ndodh dhe sa kemi përparuar.

Përparësitë e vizionit vizual të detyrave:

• Kauzaliteti. Çdo detyrë të çon në një qëllim global. Detyrat grupohen në qëllime më të vogla. Vetë domeni i infrastrukturës është mjaft teknik. Nuk është gjithmonë e qartë menjëherë se çfarë ndikimi specifik ka në biznes, për shembull, shkrimi i një libri për migrimin në një tjetër nginx. Të kesh kartën e synuar pranë e bën më të qartë.
  
  Shkakësia është një veti e rëndësishme e problemeve. Ai i përgjigjet drejtpërdrejt pyetjes: "A po bëj gjënë e duhur?"
• Paralelizmi. Jemi nëntë prej nesh dhe është thjesht e pamundur fizikisht t'i hedhësh të gjithë në një detyrë. Detyrat nga një fushë mund të mos jenë gjithmonë të mjaftueshme. Jemi të detyruar të paralelizojmë punën mes grupeve të vogla të punës. Në të njëjtën kohë, grupet ulen në detyrën e tyre për ca kohë, ato mund të përforcohen nga dikush tjetër. Ndonjëherë njerëzit largohen nga ky grup pune. Dikush shkon me pushime, dikush bën një raport për conf DevOps, dikush shkruan një artikull në Habr. Njohja se cilat synime dhe detyra mund të bëhen paralelisht bëhet shumë e rëndësishme.

2. Zëvendësimi i prezantuesve të takimeve të mëngjesit. Në stand-up kemi këtë problem - njerëzit bëjnë shumë detyra paralelisht. Ndonjëherë detyrat janë të lidhura lirshëm dhe nuk ka kuptim se kush po bën çfarë. Dhe mendimi i një anëtari tjetër të ekipit është shumë i rëndësishëm. Ky është informacion shtesë që mund të ndryshojë rrjedhën e zgjidhjes së problemit. Sigurisht, zakonisht ka dikush me ju, por këshillat dhe këshillat janë gjithmonë të dobishme.

Për të përmirësuar këtë situatë, ne përdorëm teknikën "Ndryshimi i qëndrimit drejtues". Tani ato ndërrohen sipas një liste të caktuar dhe kjo ka efektin e vet. Kur është radha juaj, ju jeni të detyruar të zhyteni dhe të kuptoni se çfarë po ndodh në mënyrë që të organizoni një takim të mirë Scrum.

3. Demonstrimi i brendshëm. Ndihma në zgjidhjen e një problemi nga programimi në çift, vizualizimi në pemën e problemeve dhe ndihma në takimet e scrum-it në mëngjes janë të mira, por jo ideale. Në çift jeni të kufizuar vetëm nga njohuritë tuaja. Pema e detyrave ndihmon për të kuptuar globalisht se kush po bën çfarë. Dhe prezantuesi dhe kolegët në takimin e mëngjesit nuk do të zhyten thellë në problemet tuaja. Ata me siguri mund të humbasin diçka.

Zgjidhja u gjet në demonstrimin e punës së bërë me njëri-tjetrin dhe më pas diskutimin e saj. Ne takohemi një herë në javë për një orë dhe tregojmë detaje të zgjidhjeve të detyrave që kemi bërë gjatë javës së kaluar.

Gjatë demonstrimit, është e nevojshme të zbulohen detajet e detyrës dhe sigurohuni që të demonstroni funksionimin e saj.

Raporti mund të kryhet duke përdorur një listë kontrolli.1. Hyni në kontekst. Nga lindi detyra, pse ishte madje e nevojshme?

2. Si u zgjidh problemi më parë? Për shembull, kërkohej një klikim masiv i miut, ose ishte e pamundur të bëhej diçka fare.

3. Si e përmirësojmë atë. Për shembull: "Shiko, tani ka scriptosik, këtu është readme."

4. Tregoni se si funksionon. Këshillohet që të zbatoni drejtpërdrejt disa skenarë të përdoruesit. Unë dua X, bëj Y, shoh Y (ose Z). Për shembull, vendos NGINX, tymos url-në dhe marr 200 OK. Nëse veprimi është i gjatë, përgatiteni paraprakisht që të mund ta shfaqni më vonë. Këshillohet që të mos e thyeni shumë një orë para demonstrimit, nëse është i brishtë.

5. Shpjegoni se sa me sukses u zgjidh problemi, çfarë vështirësish mbeten, çfarë nuk është përfunduar, çfarë përmirësimesh janë të mundshme në të ardhmen. Për shembull, tani CLI, atëherë do të ketë automatizim të plotë në CI.

Këshillohet që çdo folës ta mbajë atë në 5-10 minuta. Nëse fjalimi juaj është padyshim i rëndësishëm dhe do të zgjasë më shumë, koordinojeni këtë paraprakisht në kanalin sre-takeover.

Pas pjesës ballë për ballë ka gjithmonë një diskutim në thread. Këtu shfaqet reagimi që na nevojitet për detyrat tona.

Si rezultat, kryhet një sondazh për të përcaktuar dobinë e asaj që po ndodh. Ky është reagim mbi thelbin e fjalimit dhe rëndësinë e detyrës.

Konkluzione të gjata dhe çfarë ka më pas

Mund të duket se toni i artikullit është disi pesimist. Kjo eshte e gabuar. Dy nivele më të ulëta të reagimit, përkatësisht testet dhe programimi në çift, funksionojnë. Jo aq i përsosur sa në zhvillimin tradicional, por ka një efekt pozitiv prej tij.

Testet, në formën e tyre aktuale, ofrojnë vetëm mbulim të pjesshëm të kodit. Shumë funksione të konfigurimit përfundojnë të patestuara. Ndikimi i tyre në punën aktuale gjatë shkrimit të kodit është i ulët. Sidoqoftë, ka një efekt nga testet e integrimit, dhe ato ju lejojnë të kryeni pa frikë rifaktorime. Kjo është një arritje e madhe. Gjithashtu, me zhvendosjen e fokusit te zhvillimi në gjuhët e nivelit të lartë (kemi python, go), problemi largohet. Dhe nuk keni nevojë për shumë kontrolle për "ngjitësin"; mjafton një kontroll i përgjithshëm i integrimit.

Puna në çift varet më shumë nga njerëz të veçantë. Ekziston faktori i detyrës dhe aftësitë tona të buta. Me disa njerëz funksionon shumë mirë, me të tjerët më keq. Sigurisht që ka përfitime nga kjo. Është e qartë se edhe nëse rregullat e punës në çift nuk respektohen mjaftueshëm, vetë fakti i kryerjes së detyrave së bashku ndikon pozitivisht në cilësinë e rezultatit. Personalisht, më duket më e lehtë dhe më e këndshme puna në çifte.

Mënyrat e nivelit më të lartë për të ndikuar në OS - planifikimi dhe puna me detyra prodhojnë saktësisht efekte: shkëmbim njohurish me cilësi të lartë dhe cilësi të përmirësuar të zhvillimit.

Përfundime të shkurtra në një rresht

• Praktikuesit e burimeve njerëzore punojnë në IaC, por me më pak efikasitet.
• Forconi atë që funksionon.
• Dilni me mekanizmat dhe praktikat tuaja kompensuese.

Burimi: www.habr.com