Infrastruktuuri koodina: kuinka ratkaista ongelmia XP:n avulla

Hei, Habr! Aiemmin valitin elämästä infrastruktuurissa koodiparadigmana enkä tarjonnut mitään nykytilanteen ratkaisemiseksi. Tänään palaan kertomaan teille, mitkä lähestymistavat ja käytännöt auttavat sinua pakenemaan epätoivon kuilusta ja ohjaamaan tilannetta oikeaan suuntaan.

Aiemmassa artikkelissa "Infrastruktuuri koodina: ensimmäinen tutustuminen" Jaoin vaikutelmani tästä alueesta, yritin pohtia tämän alueen nykytilannetta ja jopa ehdotin, että kaikkien kehittäjien tuntemat standardikäytännöt voisivat auttaa. Saattaa näyttää siltä, ​​että elämästä valitettiin paljon, mutta ehdotuksia ulospääsyksi nykyisestä tilanteesta ei ollut.

Keitä olemme, missä olemme ja mitä ongelmia meillä on

Olemme tällä hetkellä Sre Onboarding Teamissä, joka koostuu kuudesta ohjelmoijasta ja kolmesta infrastruktuuri-insinööristä. Yritämme kaikki kirjoittaa infrastruktuurin koodina (IaC). Teemme tämän, koska osaamme pohjimmiltaan kirjoittaa koodia ja olemme olleet "keskimääräistä parempia" kehittäjiä.

• Meillä on joukko etuja: tietty tausta, käytäntöjen tuntemus, kyky kirjoittaa koodia, halu oppia uusia asioita.
• Ja siinä on painuva osa, joka on myös miinus: infrastruktuurilaitteistojen tietämyksen puute.

Teknologiapino, jota käytämme IaC:ssämme.

• Terraformi resurssien luomiseen.
• Pakkaaja kuvien kokoamiseen. Nämä ovat Windows, CentOS 7 -kuvia.
• Jsonnet tehokkaan koontiversion tekemiseen drone.io:ssa sekä packer jsonin ja terraform-moduuliemme luomiseen.
• Azure.
• Soveltuu kuvien valmistelussa.
• Python apupalveluihin ja provisiointiskripteihin.
• Ja kaikki tämä VSCodessa tiimin jäsenten kesken jaetuilla laajennuksilla.

Johtopäätös omastani viimeinen artikkeli oli tällainen: Yritin juurruttaa (ensisijaisesti itseeni) optimismia, halusin sanoa, että kokeilemme tuntemiamme lähestymistapoja ja käytäntöjä, jotta voimme käsitellä tällä alueella vallitsevia vaikeuksia ja monimutkaisia ​​asioita.

Kamppailemme tällä hetkellä seuraavien IaC-ongelmien kanssa:

• Koodikehityksen työkalujen ja keinojen epätäydellisyys.
• Hidas käyttöönotto. Infrastruktuuri on osa todellista maailmaa, ja se voi olla hidasta.
• Lähestymistapojen ja käytäntöjen puute.
• Olemme uusia emmekä tiedä paljon.

Extreme Programming (XP) apuun

Kaikki kehittäjät tuntevat Extreme Programmingin (XP) ja sen taustalla olevat käytännöt. Monet meistä ovat työskennelleet tämän lähestymistavan parissa, ja se on onnistunut. Joten miksi et käyttäisi siellä esitettyjä periaatteita ja käytäntöjä infrastruktuurihaasteiden voittamiseksi? Päätimme omaksua tämän lähestymistavan ja katsoa mitä tapahtuu.

XP-lähestymistavan soveltuvuuden tarkistaminen toimialallasiTässä on kuvaus ympäristöstä, johon XP sopii hyvin, ja miten se liittyy meihin:

1. Dynaamisesti muuttuvat ohjelmistovaatimukset. Meille oli selvää, mikä oli lopputavoite. Mutta yksityiskohdat voivat vaihdella. Päätämme itse, mihin taksaamme, joten vaatimukset muuttuvat ajoittain (pääasiassa itse). Jos otamme SRE-tiimin, joka tekee automaation itse ja myös rajoittaa vaatimuksia ja työn laajuutta, niin tämä kohta sopii hyvin.

2. Uutta teknologiaa käyttävien määräaikaisten projektien aiheuttamat riskit. Saatamme kohdata riskejä käyttäessämme joitain meille tuntemattomia asioita. Ja tämä on 100% meidän tapaus. Koko projektimme oli sellaisten teknologioiden käyttöä, joita emme olleet täysin tunteneet. Yleensä tämä on jatkuva ongelma, koska... Infrastruktuurialalla syntyy jatkuvasti monia uusia teknologioita.

3,4. Pieni, samassa paikassa oleva laajennettu kehitystiimi. Käyttämäsi automatisoitu tekniikka mahdollistaa yksikkö- ja toimintatestit. Nämä kaksi kohtaa eivät oikein sovi meille. Ensinnäkin emme ole koordinoitu tiimi, ja toiseksi meitä on yhdeksän, jota voidaan pitää suurena tiiminä. Vaikka joidenkin "suuren" joukkueen määritelmien mukaan paljon on 14+ henkilöä.

Katsotaanpa joitain XP-käytäntöjä ja kuinka ne vaikuttavat palautteen nopeuteen ja laatuun.

XP:n palautesilmukan periaate

Ymmärtääkseni palaute on vastaus kysymykseen, teenkö oikein, mennäänkö sinne? XP:llä on jumalallinen järjestelmä tähän: aikapalautesilmukka. Mielenkiintoista on, että mitä alempana olemme, sitä nopeammin saamme käyttöjärjestelmän vastaamaan tarvittaviin kysymyksiin.

Tämä on melko mielenkiintoinen keskustelunaihe, että IT-alallamme on mahdollista saada käyttöjärjestelmä nopeasti. Kuvittele kuinka tuskallista on tehdä projektia kuusi kuukautta ja vasta sitten huomata, että siinä oli virhe aivan alussa. Tämä tapahtuu suunnittelussa ja kaikissa monimutkaisten järjestelmien rakentamisessa.

Meidän tapauksessamme IaC:ssä palaute auttaa meitä. Teen heti pienen säädön yllä olevaan kaavioon: julkaisusuunnitelmassa ei ole kuukausittaista kiertoa, vaan se tapahtuu useita kertoja päivässä. Tähän käyttöjärjestelmäsykliin liittyy joitain käytäntöjä, joita tarkastelemme yksityiskohtaisemmin.

Tärkeää: palaute voi olla ratkaisu kaikkiin edellä mainittuihin ongelmiin. Yhdessä XP-käytäntöjen kanssa se voi vetää sinut ulos epätoivon kuilusta.

Kuinka vetää itsesi pois epätoivon kuilusta: kolme käytäntöä

testit

Testit mainitaan kahdesti XP:n palautesilmukassa. Se ei ole vain niin. Ne ovat erittäin tärkeitä koko Extreme Programming -tekniikan kannalta.

Oletetaan, että sinulla on yksikkö- ja hyväksymistestit. Jotkut antavat sinulle palautteen muutamassa minuutissa, toiset muutamassa päivässä, joten niiden kirjoittaminen kestää kauemmin ja niitä tarkistetaan harvemmin.

On olemassa klassinen testauspyramidi, joka osoittaa, että testejä pitäisi olla enemmän.

Miten tämä viitekehys koskee meitä IaC-projektissa? Itse asiassa... ei ollenkaan.

• Yksikkötestejä, vaikka niitä pitäisi olla paljon, ei voi olla liikaa. Tai he testaavat jotain hyvin epäsuorasti. Itse asiassa voimme sanoa, että emme kirjoita niitä ollenkaan. Mutta tässä on muutamia sovelluksia tällaisia ​​testejä varten, jotka pystyimme tekemään:
  1. Jsonnet-koodin testaus. Tämä on esimerkiksi droonien kokoonpanoputkistomme, joka on melko monimutkainen. Jsonnet-koodi on hyvin testattu.
     Käytämme tätä Yksikkötestauskehys Jsonnetille.
  2. Testaa komentosarjoja, jotka suoritetaan resurssin käynnistyessä. Skriptit kirjoitetaan Pythonilla, joten niille voidaan kirjoittaa testejä.
• Kokoonpanon tarkistaminen testeissä on mahdollisesti mahdollista, mutta emme tee niin. On myös mahdollista konfiguroida resurssien määrityssääntöjen tarkistusta kautta tflint. Siellä olevat tarkistukset ovat kuitenkin yksinkertaisesti liian yksinkertaisia ​​terraformille, mutta monet testiskriptit on kirjoitettu AWS:lle. Ja olemme Azuressa, joten tämä taas ei päde.
• Komponenttien integrointitestit: se riippuu siitä, kuinka luokittelet ne ja mihin sijoitat ne. Mutta periaatteessa ne toimivat.

  Tältä integraatiotestit näyttävät.

  
  
  Tämä on esimerkki kuvien rakentamisesta Drone CI:ssä. Päästäksesi niihin, sinun on odotettava 30 minuuttia, jotta Packer-kuva muodostuu, ja sitten vielä 15 minuuttia, jotta ne ohittavat. Mutta niitä on olemassa!

  Kuvan vahvistusalgoritmi

  1. Pakkaajan on ensin valmisteltava kuva kokonaan.
  2. Testin vieressä on terraform, jossa on paikallinen tila, jota käytämme tämän kuvan käyttöönotossa.
  3. Avattaessa käytetään pientä lähellä olevaa moduulia, joka helpottaa kuvan käsittelyä.
  4. Kun VM on otettu käyttöön kuvasta, tarkistukset voivat alkaa. Periaatteessa tarkastukset tehdään autolla. Se tarkistaa, kuinka komentosarjat toimivat käynnistyksen yhteydessä ja kuinka demonit toimivat. Tätä varten kirjaudumme ssh:n tai winrm:n kautta äskettäin esille nostettuun koneeseen ja tarkistamme asetusten tilan tai onko palvelut päällä.

• Tilanne on samanlainen terraformin moduulien integrointitestien kanssa. Tässä on lyhyt taulukko, joka selittää tällaisten testien ominaisuudet.

  
  
  Palaute putkistosta on noin 40 minuuttia. Kaikki tapahtuu hyvin pitkään. Sitä voidaan käyttää regressioon, mutta uudelle kehitykselle se on yleensä epärealistista. Jos olet hyvin, hyvin valmistautunut tähän, valmistele käynnissä olevat skriptit, voit lyhentää sen 10 minuuttiin. Mutta nämä eivät silti ole yksikkötestejä, jotka tekevät 5 kappaletta 100 sekunnissa.

Yksikkötestien puuttuminen kuvia tai terraformmoduuleita koottaessa rohkaisee työn siirtämistä erillisiin palveluihin, jotka voidaan suorittaa yksinkertaisesti RESTin kautta, tai Python-skripteihin.

Meidän piti esimerkiksi varmistaa, että kun virtuaalikone käynnistyy, se rekisteröi itsensä palveluun ScaleFT, ja kun virtuaalikone tuhoutui, se poisti itsensä.

Koska meillä on ScaleFT palveluna, meidän on pakko työskennellä sen kanssa API:n kautta. Sinne oli kirjoitettu kääre, josta saattoi vetää ja sanoa: "Mene sisään ja poista tämä ja tuo." Se tallentaa kaikki tarvittavat asetukset ja käyttöoikeudet.

Tätä varten voimme jo kirjoittaa normaaleja testejä, koska se ei eroa tavallisista ohjelmistoista: jonkinlaista apihaa pilkataan, vedät sen ja katsot mitä tapahtuu.

Testien tulokset: Yksikkötestaus, jonka pitäisi antaa käyttöjärjestelmä minuutissa, ei anna sitä. Ja pyramidin korkeammalla olevat testaustyypit ovat tehokkaita, mutta kattavat vain osan ongelmista.

Pariohjelmointi

Testit ovat tietysti hyviä. Voit kirjoittaa niitä paljon, ne voivat olla erilaisia. He työskentelevät omalla tasollaan ja antavat meille palautetta. Mutta ongelma huonoissa yksikkötesteissä, jotka antavat nopeimman käyttöjärjestelmän, säilyy. Samalla haluan silti nopean käyttöjärjestelmän, jonka kanssa on helppo ja miellyttävä työskennellä. Puhumattakaan tuloksena olevan ratkaisun laadusta. Onneksi on tekniikoita, jotka voivat antaa jopa nopeampaa palautetta kuin yksikkötestit. Tämä on pariohjelmointia.

Koodia kirjoitettaessa halutaan saada palautetta sen laadusta mahdollisimman nopeasti. Kyllä, voit kirjoittaa kaiken ominaisuushaaraan (jotta et rikkoisi mitään), tehdä vetopyynnön Githubissa, määrittää sen jollekulle, jonka mielipiteellä on painoarvoa, ja odottaa vastausta.

Mutta voit odottaa pitkään. Ihmiset ovat kaikki kiireisiä, ja vastaus, vaikka sellainen olisi, ei välttämättä ole laadukkain. Oletetaan, että vastaus tuli heti, arvioija ymmärsi heti koko idean, mutta vastaus tulee silti myöhään, jälkikäteen. Toivon, että se olisi aikaisemmin. Tähän pariohjelmointi on tarkoitettu – heti kirjoittamisen yhteydessä.

Alla on pariohjelmointityylit ja niiden soveltuvuus IaC-työskentelyyn:

1. Classic, Experienced+Experienced, vuorottelu ajastimella. Kaksi roolia – kuljettaja ja navigaattori. Kaksi henkilöä. He työskentelevät samalla koodilla ja vaihtavat rooleja tietyn ennalta määrätyn ajan kuluttua.

Mietitäänpä ongelmien yhteensopivuutta tyylin kanssa:

• Ongelma: koodinkehityksen työkalujen ja työkalujen epätäydellisyys.
  Negatiivinen vaikutus: kehittyminen kestää kauemmin, hidastuu, työn tahti/rytmi katoaa.
  Kuinka taistelemme: käytämme erilaisia ​​työkaluja, yhteistä IDE:tä ja opimme myös pikakuvakkeita.
• Ongelma: Hidas käyttöönotto.
  Negatiivinen vaikutus: lisää aikaa, joka kuluu toimivan koodinpätkän luomiseen. Kyllästymme odottaessamme, kätemme ojentuvat tehdäksemme jotain muuta odottaessamme.
  Kuinka taistelemme: emme voittanut sitä.
• Ongelma: lähestymistapojen ja käytäntöjen puute.
  Negatiivinen vaikutus: ei tiedetä, miten se tehdään hyvin ja miten se tehdään huonosti. Pidentää palautteen vastaanottoa.
  Kuinka taistelemme: molemminpuolinen mielipiteiden ja käytäntöjen vaihto parityössä melkein ratkaisee ongelman.

Suurin ongelma tämän tyylin käytössä IaC:ssä on epätasainen työtahti. Perinteisessä ohjelmistokehityksessä liike on hyvin yhtenäistä. Voit käyttää viisi minuuttia ja kirjoittaa N. Vietä 10 minuuttia ja kirjoittaa 2N, 15 minuuttia - 3N. Täällä voit viettää viisi minuuttia ja kirjoittaa N, ja sitten viettää vielä 30 minuuttia ja kirjoittaa kymmenesosan N:stä. Täällä et tiedä mitään, olet jumissa, tyhmä. Tutkinta vie aikaa ja häiritsee itse ohjelmointia.

Johtopäätös: puhtaassa muodossaan se ei sovi meille.

2. Ping-pong. Tämä lähestymistapa edellyttää, että yksi henkilö kirjoittaa testin ja toinen suorittaa sen toteutuksen. Ottaen huomioon, että yksikkötesteissä kaikki on monimutkaista ja joudut kirjoittamaan integraatiotestin, jonka ohjelmointi kestää kauan, kaikki ping-pongin helppous katoaa.

Voin sanoa, että yritimme erottaa vastuut testiskriptin suunnittelusta ja koodin toteuttamisesta sille. Yksi osallistuja keksi käsikirjoituksen, tässä työssä hän oli vastuussa, hänellä oli viimeinen sana. Ja toinen oli vastuussa toteutuksesta. Se onnistui hyvin. Käsikirjoituksen laatu paranee tällä lähestymistavalla.

Johtopäätös: valitettavasti työn nopeus ei salli ping-pongin käyttöä pariohjelmointikäytäntönä IaC:ssä.

3. Vahva tyyli. Vaikea harjoitus. Ajatuksena on, että yhdestä osallistujasta tulee käskynavigaattori, ja toisesta tulee suoritusohjaimen rooli. Tässä tapauksessa oikeus tehdä päätöksiä on yksinomaan navigaattorilla. Kuljettaja vain tulostaa ja voi vaikuttaa sanalla tapahtuvaan. Roolit eivät vaihda pitkään aikaan.

Hyvä oppimiseen, mutta vaatii vahvoja pehmeitä taitoja. Tässä me horjuimme. Tekniikka oli vaikea. Eikä kyse ole edes infrastruktuurista.

Johtopäätös: sitä voidaan mahdollisesti käyttää, emme anna periksi yrittää.

4. Mobbing, swarming ja kaikki tunnetut mutta eivät luetellut tyylit Emme ota sitä huomioon, koska Emme ole kokeilleet sitä, ja siitä on mahdotonta puhua työmme yhteydessä.

Yleisiä tuloksia pariohjelmoinnin käytöstä:

• Meillä on epätasainen työtahti, mikä on hämmentävää.
• Törmäsimme riittämättömästi hyviin pehmeisiin taitoihin. Ja aihealue ei auta voittamaan näitä puutteitamme.
• Pitkät testit ja ongelmat työkalujen kanssa tekevät parikehityksen vaikeaksi.

5. Tästä huolimatta onnistumisia oli. Keksimme oman menetelmämme "Convergence - Divergence". Kerron lyhyesti kuinka se toimii.

Meillä on vakituisia yhteistyökumppaneita muutaman päivän (alle viikon). Teemme yhdessä yhden tehtävän. Istumme yhdessä hetken: toinen kirjoittaa, toinen istuu ja katselee tukitiimiä. Sitten hajallaan jonkin aikaa, kumpikin tekee itsenäisiä asioita, sitten palaamme yhteen, synkronoimme hyvin nopeasti, teemme jotain yhdessä ja hajallaan taas.

Suunnittelu ja viestintä

Viimeinen käytäntölohko, jonka kautta käyttöjärjestelmäongelmia ratkaistaan, on työn organisointi itse tehtävien kanssa. Tämä sisältää myös kokemusten vaihdon parityön ulkopuolella. Katsotaanpa kolmea käytäntöä:

1. Tavoitteet tavoitepuun kautta. Järjestimme projektin kokonaisjohtamisen puun kautta, joka ulottuu loputtomasti tulevaisuuteen. Teknisesti seuranta tapahtuu Mirossa. On yksi tehtävä - se on välitavoite. Siitä lähtevät joko pienemmät tavoitteet tai tehtäväryhmät. Itse tehtävät tulevat heiltä. Kaikki tehtävät luodaan ja ylläpidetään tällä taululla.

Tämä järjestelmä antaa myös palautetta, joka tapahtuu kerran päivässä, kun synkronoimme mielenosoituksissa. Yhteinen suunnitelma kaikkien edessä, mutta jäsennelty ja täysin avoin antaa kaikille mahdollisuuden olla tietoinen siitä, mitä tapahtuu ja kuinka pitkälle olemme edistyneet.

Tehtävien visuaalisen näkemyksen edut:

• Syy-seuraus. Jokainen tehtävä johtaa johonkin globaaliin tavoitteeseen. Tehtävät ryhmitellään pienempiin tavoitteisiin. Infrastruktuurialue itsessään on melko tekninen. Ei aina ole heti selvää, mitä konkreettista vaikutusta liiketoimintaan on esimerkiksi runbookin kirjoittamisella siirtymisestä toiseen nginxiin. Kun kohdekortti on lähellä, se on selkeämpi.
  
  Syy-yhteys on ongelmien tärkeä ominaisuus. Se vastaa suoraan kysymykseen: "Teenkö oikein?"
• Rinnakkaisuus. Meitä on yhdeksän, ja on yksinkertaisesti fyysisesti mahdotonta heittää kaikki samaan tehtävään. Myöskään yhden alueen tehtävät eivät välttämättä aina riitä. Meidän on pakko rinnastaa työskentely pienten työryhmien välillä. Samaan aikaan ryhmät istuvat jonkin aikaa tehtävällään, he voivat saada vahvistusta jonkun muun toimesta. Joskus ihmiset jäävät pois tästä työryhmästä. Joku lähtee lomalle, joku tekee raportin DevOps-konferenssiin, joku kirjoittaa artikkelin Habrista. On erittäin tärkeää tietää, mitä tavoitteita ja tehtäviä voidaan tehdä rinnakkain.

2. Aamukokousten sijaispuheenjohtajat. Stand-upissa meillä on tämä ongelma - ihmiset tekevät monia tehtäviä rinnakkain. Joskus tehtävät liittyvät löyhästi, eikä käsitystä siitä, kuka tekee mitäkin. Ja toisen tiimin jäsenen mielipide on erittäin tärkeä. Tämä on lisätietoa, joka voi muuttaa ongelman ratkaisun kulkua. Tietysti yleensä joku on mukana, mutta neuvoista ja vinkeistä on aina hyötyä.

Tämän tilanteen parantamiseksi käytimme "Johtavan seisomisen muuttaminen" -tekniikkaa. Nyt niitä kierretään tietyn listan mukaan, ja tämä vaikuttaa. Kun on sinun vuorosi, sinun on pakko sukeltaa sisään ja ymmärtää, mitä tapahtuu, jotta voit järjestää hyvän Scrum-kokouksen.

3. Sisäinen demo. Apu ongelman ratkaisemiseen pariohjelmoinnista, visualisoinnista ongelmapuussa ja apu aamuisin scrum-kokouksissa ovat hyviä, mutta eivät ihanteellisia. Parina teitä rajoittaa vain tietonne. Tehtäväpuu auttaa maailmanlaajuisesti ymmärtämään, kuka tekee mitä. Ja juontaja ja kollegat aamukokouksessa eivät sukeltaa syvälle ongelmiisi. Heiltä saattaa varmasti jäädä jotain paitsi.

Ratkaisu löytyi esittelemällä toisilleen tehtyä työtä ja sitten keskustelemalla siitä. Kokoonnumme kerran viikossa tunnin ajaksi ja näytämme yksityiskohtia viime viikon aikana tekemiemme tehtävien ratkaisuista.

Esittelyn aikana on tarpeen paljastaa tehtävän yksityiskohdat ja muistaa osoittaa sen toiminta.

Raportti voidaan tehdä tarkistuslistalla.1. Mene kontekstiin. Mistä tehtävä tuli, miksi se oli edes tarpeen?

2. Miten ongelma ratkaistiin aiemmin? Esimerkiksi massiivinen hiiren napsauttaminen vaadittiin tai ei ollut mahdollista tehdä mitään.

3. Kuinka parannamme sitä. Esimerkiksi: "Katso, nyt on scriptosik, tässä on readme."

4. Näytä, miten se toimii. On suositeltavaa toteuttaa suoraan jokin käyttäjän skenaario. Haluan X, teen Y, näen Y (tai Z). Esimerkiksi otan käyttöön NGINX:n, poltan URL-osoitteen ja saan 200 OK. Jos toiminto on pitkä, valmistele se etukäteen, jotta voit näyttää sen myöhemmin. On suositeltavaa olla rikkomatta sitä liikaa tuntia ennen demoa, jos se on hauras.

5. Selitä, kuinka onnistuneesti ongelma ratkesi, mitä vaikeuksia on jäljellä, mikä on kesken, mitä parannuksia on mahdollista tehdä tulevaisuudessa. Esimerkiksi nyt CLI, silloin CI:ssä on täysi automaatio.

Jokaisen kaiuttimen on suositeltavaa pitää se 5-10 minuuttia. Jos puheesi on selvästi tärkeä ja kestää kauemmin, sovita tämä etukäteen sre-takeover-kanavalla.

Kasvokkain-osuuden jälkeen ketjussa on aina keskustelua. Tässä näkyy palaute, jota tarvitsemme tehtävistämme.

Tämän seurauksena tehdään kysely, jolla selvitetään tapahtumien hyödyllisyyttä. Tämä on palaute puheen olemuksesta ja tehtävän tärkeydestä.

Pitkät johtopäätökset ja mitä seuraavaksi

Saattaa vaikuttaa siltä, ​​että artikkelin sävy on jokseenkin pessimistinen. Tämä on väärin. Kaksi alempaa palautetasoa, nimittäin testit ja pariohjelmointi, toimivat. Ei niin täydellinen kuin perinteisessä kehityksessä, mutta sillä on positiivinen vaikutus.

Testit tarjoavat nykyisessä muodossaan vain osittaisen koodin peiton. Monet konfigurointitoiminnot jäävät testaamatta. Niiden vaikutus varsinaiseen työhön koodia kirjoitettaessa on vähäinen. Integrointitesteillä on kuitenkin vaikutusta, ja niiden avulla voit tehdä pelottomasti refaktorointia. Tämä on hieno saavutus. Lisäksi, kun painopiste siirtyy korkean tason kielten kehittämiseen (meillä on python, go), ongelma poistuu. Eikä "liimaa" tarvitse paljon tarkastaa, vaan yleinen integraatiotarkastus riittää.

Parityöskentely riippuu enemmän tietyistä ihmisistä. Siinä on tehtävätekijä ja pehmeät taitomme. Toisilla se toimii erittäin hyvin, toisilla huonommin. Tästä on varmasti hyötyä. On selvää, että vaikka parityöskentelyn sääntöjä ei noudatettaisi riittävästi, jo pelkästään tehtävien suorittaminen yhdessä vaikuttaa positiivisesti tuloksen laatuun. Henkilökohtaisesti parityöskentely on mielestäni helpompaa ja nautinnollisempaa.

Korkeamman tason tavat vaikuttaa käyttöjärjestelmään - tehtävien täsmällinen suunnittelu ja työskentely tuottavat tehosteita: laadukasta tiedonvaihtoa ja kehityslaadun paranemista.

Lyhyet johtopäätökset yhdellä rivillä

• HR-ammattilaiset työskentelevät IaC:ssä, mutta heikommin tehokkuudella.
• Vahvista mikä toimii.
• Keksi omia kompensointimekanismejasi ja käytäntöjäsi.

Lähde: will.com