Eingeymsla: vinsamlegast, verð

Eingeymsla: vinsamlegast, verð

Þýðing á greininni unnin fyrir nemendur á námskeiðinu „DevOps venjur og verkfæri“ í OTUS fræðsluverkefninu.

Þú ættir að velja eingeymsla vegna þess að hegðunin sem það stuðlar að í teymunum þínum er gagnsæi og sameiginleg ábyrgð, sérstaklega þegar teymum stækkar. Hvort heldur sem er, þú verður að fjárfesta í verkfærum, en það er alltaf betra ef sjálfgefin hegðun er sú hegðun sem þú vilt í skipunum þínum.

Af hverju erum við að tala um þetta?

Matt Klein skrifaði greinina "Monorepos: Vinsamlegast ekki!"  (athugasemd þýðanda: þýðing á Habré „Eingeymslur: vinsamlegast ekki“). Mér líkar við Matt, mér finnst hann mjög klár og þú ættir að lesa sjónarhorn hans. Hann birti könnunina upphaflega á Twitter:

Eingeymsla: vinsamlegast, verð

Þýðing:
Núna á nýársdag ætla ég að rífast um hversu fáránlegar eingeymslur eru. Árið 2019 byrjaði rólega. Í anda þessa býð ég þér upp á könnun. Hverjir eru stóru ofstækismennirnir? Stuðningsmenn:
- Monorepo
- Ryð
- Röng könnun / bæði

Svar mitt var: "Ég er bókstaflega bæði þetta fólk." Í stað þess að tala um hvernig Rust er eiturlyf, skulum við skoða hvers vegna ég held að hann hafi rangt fyrir sér varðandi eingeymslur. Smá um sjálfan þig. Ég er tæknistjóri Chef Software. Við erum með um 100 verkfræðinga, kóðagrunn sem nær um 11-12 ár aftur í tímann og 4 aðalvörur. Sumt af þessum kóða er í fjölgeymslu (upphafsstaða mín), önnur er í eingeymslu (núverandi staða mín).

Áður en ég byrja: öll rök sem ég set hér fram munu eiga við um báðar tegundir geymslu. Að mínu mati er engin tæknileg ástæða fyrir því að þú ættir að velja eina tegund geymslu umfram aðra. Þú getur látið hvaða nálgun sem er. Ég er fús til að tala um það, en ég hef ekki áhuga á tilbúnum tæknilegum ástæðum hvers vegna einn er æðri öðrum.

Ég er sammála fyrri hluta punkts Matts:

Vegna þess að í mælikvarða mun eingeymsla leysa öll sömu vandamálin og fjölgeymsla leysir, en á sama tíma neyða þig til að tengja kóðann þinn þétt og krefjast ótrúlegrar viðleitni til að auka sveigjanleika útgáfustýringarkerfisins.

Þú verður að leysa sömu vandamálin óháð því hvort þú velur eingeymsla eða fjölgeymslu. Hvernig gefur þú út útgáfur? Hver er nálgun þín við uppfærslur? Afturábak eindrægni? Þverfagnað verkefna? Hvaða byggingarstílar eru ásættanlegir? Hvernig stjórnar þú uppbyggingu og prófunarinnviðum þínum? Listinn er endalaus. Og þú munt leysa þau öll þegar þú stækkar. Það er enginn ókeypis ostur.

Ég held að rök Matta séu svipuð skoðunum sem margir verkfræðingar (og stjórnendur) deila sem ég virði. Þetta gerist frá sjónarhóli verkfræðingsins sem vinnur við íhlutinn eða teymið sem vinnur við íhlutinn. Þú heyrir hluti eins og:

  • Kóðagrunnurinn er fyrirferðarmikill - ég þarf ekki allt þetta drasl.
  • Það er erfiðara að prófa því ég þarf að prófa allt þetta drasl sem ég þarf ekki.
  • Það er erfiðara að vinna með ytri ósjálfstæði.
  • Ég þarf eigin sýndarútgáfustýringarkerfi.

Auðvitað eru öll þessi atriði réttlætanleg. Þetta gerist í báðum tilfellum - í fjölgeymslunni er ég með mitt eigið drasl, fyrir utan það sem þarf til að byggja... Ég gæti líka þurft annað drasl. Svo ég "einfaldlega" bý til verkfæri sem athuga allt verkefnið. Eða ég bý til falsa eingeymslu með undireiningum. Við gátum gengið um þetta allan daginn. En ég held að málflutningur Matt missi af aðalástæðunni, sem ég snéri ansi mikið í þágu eingeymslunnar:

Það vekur samskipti og sýnir vandamál

Þegar við aðskiljum geymslur búum við til raunverulegt samræmingar- og gagnsæisvandamál. Þetta samsvarar því hvernig við hugsum um lið (sérstaklega hvernig einstakir meðlimir hugsa um þau): við berum ábyrgð á ákveðnum þætti. Við vinnum í tiltölulega einangrun. Mörkin eru föst á liðinu mínu og þeim þáttum sem við erum að vinna að.

Eftir því sem arkitektúr verður flóknari getur eitt teymi ekki lengur stjórnað því eitt. Örfáir verkfræðingar eru með allt kerfið í hausnum. Segjum að þú hafir umsjón með sameiginlegum íhlut A sem er notaður af liðum B, C og D. Lið A er að endurskipuleggja, bæta API og einnig að breyta innri útfærslu. Þess vegna eru breytingarnar ekki afturábak samhæfðar. Hvaða ráð hefur þú?

  • Finndu alla staði þar sem gamla API er notað.
  • Eru staðir þar sem ekki er hægt að nota nýja API?
  • Geturðu lagað og prófað aðra íhluti til að tryggja að þeir brotni ekki?
  • Geta þessi lið prófað breytingarnar þínar núna?

Vinsamlegast athugaðu að þessar spurningar eru óháðar gerð geymslunnar. Þú þarft að finna lið B, C og D. Þú þarft að tala við þau, finna út tímann, skilja forgangsröðun þeirra. Við vonum að minnsta kosti að þú gerir það.

Það vill í raun enginn gera þetta. Þetta er miklu minna gaman en bara að laga fjandans API. Þetta er allt mannlegt og sóðalegt. Í fjölgeymslu geturðu einfaldlega gert breytingar, gefið það fólki sem vinnur að þeim íhlut (líklega ekki B, C eða D) til skoðunar og haldið áfram. Liðin B, C og D geta bara verið með núverandi útgáfu í bili. Þeir verða endurnýjaðir þegar þeir átta sig á snilli þinni!

Í eingeymslu er ábyrgð færð sjálfgefið. A lið breytir um íhlut og, ef ekki er varkár, brýtur strax B, C og D. Þetta leiðir til þess að B, C og D mæta við hurðina hjá A og velta því fyrir sér hvers vegna lið A braut samstæðuna. Þetta kennir A að þeir geta ekki sleppt listanum mínum hér að ofan. Þeir verða að tala um hvað þeir ætla að gera. Geta B, C og D hreyft sig? Hvað ef B og C geta, en D var nátengd aukaverkun af hegðun gamla reikniritsins?

Þá verðum við að tala um hvernig við munum komast út úr þessari stöðu:

  1. Stuðningur við mörg innri API og mun merkja gamla reikniritið sem úrelt þar til D getur hætt að nota það.
  2. Stuðningur við margar útgáfur, eina með gamla viðmótinu, eina með því nýja.
  3. Fresta útgáfu breytinga A þar til B, C og D geta samtímis samþykkt þær.

Segjum að við höfum valið 1, nokkur API. Í þessu tilfelli höfum við tvö stykki af kóða. Gamalt og nýtt. Mjög þægilegt í sumum aðstæðum. Við tökum gamla kóðann aftur inn, merkjum hann sem úreltan og samþykkjum fjarlægingaráætlun við D-liðið. Í meginatriðum eins fyrir fjöl- og ein-geymsla.

Til að gefa út margar útgáfur þurfum við útibú. Nú höfum við tvo þætti - A1 og A2. Lið B og C nota A2 og D notar A1. Við þurfum að allir íhlutir séu tilbúnir til útgáfu vegna þess að öryggisuppfærslur og aðrar villuleiðréttingar gætu verið nauðsynlegar áður en D getur haldið áfram. Í fjölgeymslu getum við falið þetta í langlífri grein sem líður vel. Í eingeymslu þvingum við kóðann til að búa til í nýrri einingu. Lið D mun samt þurfa að gera breytingar á "gamla" þættinum. Allir geta séð kostnaðinn sem við erum að borga hér - við erum núna með tvöfalt meiri kóða og allar villuleiðréttingar sem eiga við um A1 og A2 verða að eiga við um þær báðar. Með greiningaraðferðinni í fjölgeymslu er þetta falið á bak við kirsuberjatínslu. Við teljum kostnaðinn vera lægri þar sem ekki er um tvíverknað að ræða. Frá hagnýtu sjónarhorni er kostnaðurinn sá sami: þú munt byggja, gefa út og viðhalda tveimur að mestu eins kóðabasa þar til þú getur eytt einum þeirra. Munurinn er sá að með eingeymslu er þessi sársauki bein og sýnileg. Þetta er enn verra og það er gott.

Að lokum komum við að þriðja atriðinu. Losun seinkun. Hugsanlegt er að breytingar sem A gerir muni bæta líf liðs A. Mikilvægt, en ekki brýnt. Getum við bara frestað? Í fjölgeymslu ýtum við á þetta til að festa gripinn. Auðvitað erum við að segja þetta við Team D. Vertu bara á gömlu útgáfunni þangað til þú nærð þér! Þetta setur þig upp til að leika hugleysinginn. Lið A heldur áfram að vinna að sínum hluta og hunsar þá staðreynd að D-liðið notar sífellt úrelta útgáfu (það er vandamál D-liðsins, þeir eru heimskir). Á meðan talar D-liðið illa um kærulausa afstöðu liðs A til kóðastöðugleika, ef þeir tala um það yfirleitt. Mánuðir líða. Að lokum ákveður D-liðið að skoða möguleika á uppfærslu, en A hefur aðeins fleiri breytingar. A lið man varla hvenær eða hvernig þeir brutu D. Uppfærslan er sársaukafyllri og mun taka lengri tíma. Sem sendir það lengra niður í forgangsstafla. Þangað til daginn sem við höfum öryggisvandamál í A sem neyðir okkur til að búa til útibú. Lið A verður að fara aftur í tímann, finna stað þar sem D var stöðugt, laga vandamálið þar og gera það tilbúið til útgáfu. Þetta er raunverulegt val sem fólk tekur og það er lang versta. Það virðist vera gott fyrir bæði A og D lið svo lengi sem við getum hunsað hvort annað.

Í eingeymslu er sú þriðja í raun ekki valkostur. Þú neyðist til að takast á við ástandið á annan af tveimur vegu. Þú þarft að sjá kostnaðinn við að hafa tvær útgáfugreinar. Lærðu að verja þig fyrir uppfærslum sem brjóta afturábak eindrægni. En mikilvægast: þú kemst ekki hjá því að eiga erfitt samtal.

Það er mín reynsla að þegar lið verða stór er ekki lengur hægt að hafa allt kerfið í huga og það er mikilvægasti hlutinn. Þú verður að bæta sýnileika ósættis í kerfinu. Þú verður að vinna virkan að því að fá teymi til að líta í burtu frá hlutum sínum og skoða vinnu annarra teyma og neytenda.

Já, þú getur búið til verkfæri sem reyna að leysa fjölgeymsluvandann. En reynsla mín af því að kenna stöðuga afhendingu og sjálfvirkni í stórum fyrirtækjum segir mér þetta: sjálfgefin hegðun án þess að nota viðbótartæki er hegðunin sem þú býst við að sjá. Sjálfgefin hegðun fjölgeymsla er einangrun, það er allt málið. Sjálfgefin hegðun eingeymslu er sameiginleg ábyrgð og gagnsæi, það er málið. Í báðum tilfellum ætla ég að búa til verkfæri sem sléttir út grófu brúnirnar. Sem leiðtogi mun ég velja eingeymslu í hvert skipti vegna þess að verkfærin þurfa að styrkja þá menningu sem ég vil og menningin kemur frá örsmáum ákvörðunum og daglegu starfi liðsins.

Aðeins skráðir notendur geta tekið þátt í könnuninni. Skráðu þig inn, takk.

Hverjir eru stærstu ofstækismennirnir? Stuðningsmenn:

  • Monorepo

  • Ryð

  • Röng könnun / bæði

33 notendur kusu. 13 notendur sátu hjá.

Heimild: www.habr.com

Bæta við athugasemd