Sveiki, draugai. Laukiant kurso pradžios , tradiciškai pasidalinkite su jumis naudingos medžiagos vertimu.
Programinė įranga išsprendžia vis daugiau kasdienių užduočių ir tampa vis sudėtingesnė. Kaip kartą pasakė Marcas Andressenas, jis suryja pasaulį.
Todėl per pastaruosius kelerius metus labai pasikeitė programų kūrimo ir pristatymo būdas. Tai buvo tektoninio masto poslinkiai, dėl kurių atsirado principų rinkinys. Šie principai pasirodė esą naudingi kuriant komandą, kuriant, kuriant ir pateikiant jūsų taikomąją programą galutiniams vartotojams.
Principus galima apibendrinti taip: programa turi būti maža, internetinė ir turėti į kūrėją orientuotą architektūrą. Atsižvelgdami į šiuos tris principus, galite sukurti patikimą, visapusišką programą, kuri gali būti greitai ir saugiai pristatyta galutiniam vartotojui, lengvai keičiama ir išplečiama.
Kiekvienas iš siūlomų principų turi keletą aspektų, kuriuos aptarsime norėdami parodyti, kaip kiekvienas principas prisideda prie galutinio tikslo, ty greito patikimų programų, kurias būtų lengva prižiūrėti ir naudoti, pristatymo. Mes pažvelgsime į principus, susijusius su jų priešingybėmis, kad išsiaiškintume, ką tai reiškia, tarkime: „Įsitikinkite, kad naudojate mažumo principas".
Tikimės, kad šis straipsnis paskatins jus panaudoti siūlomus principus kuriant modernias programas, kurios suteiks vieningą požiūrį į dizainą vis augančio technologijų krūvos kontekste.
Taikydami šiuos principus galėsite pasinaudoti naujausiomis programinės įrangos kūrimo tendencijomis, įskaitant taikomųjų programų kūrimui ir pristatymui, konteinerių naudojimui (pvz., ) ir konteinerių orkestravimo sistemas (pvz., ), mikropaslaugų (įskaitant „Microservice Architecture“) naudojimą и mikro paslaugų programoms.
Kas yra šiuolaikinė programa?
Šiuolaikinės programos? Šiuolaikinis kaminas? Ką tiksliai reiškia „modernus“?
Daugelis kūrėjų turi tik bendrą supratimą apie tai, iš ko susideda šiuolaikinė programa, todėl būtina aiškiai apibrėžti šią sąvoką.
Šiuolaikinė programa palaiko kelis klientus, nesvarbu, ar tai būtų „React JavaScript“ bibliotekos vartotojo sąsaja, „Android“ arba „iOS“ programa mobiliesiems, ar programa, jungianti prie kitos API. Šiuolaikinė programa reiškia neribotą skaičių klientų, kuriems ji teikia duomenis ar paslaugas.
Šiuolaikinė programa suteikia API, leidžiančią pasiekti prašomus duomenis ir paslaugas. API turi būti nekintanti ir pastovi, o ne parašyta konkrečiai konkrečiai užklausai iš konkretaus kliento. API pasiekiama per HTTP(S) ir suteikia prieigą prie visų GUI arba CLI funkcijų.
Duomenys turi būti pasiekiami bendrai priimtu, suderinamu formatu, pvz., JSON. API atskleidžia objektus ir paslaugas švariai, organizuotai, pavyzdžiui, RESTful API arba GraphQL suteikia tinkamą sąsają.
Šiuolaikinės programos yra sukurtos ant šiuolaikinės dėklo, o modernus dėklas yra atitinkamai tokias programas palaikantis dėklas. Šis krūvas leidžia kūrėjui lengvai sukurti programą su HTTP sąsaja ir aiškiais API galutiniais taškais. Pasirinktas metodas leis jūsų programai lengvai gauti ir siųsti duomenis JSON formatu. Kitaip tariant, šiuolaikinė stekinė atitinka dvylikos faktorių programos elementus .
Populiarios šio tipo kamino versijos yra pagrįstos , , , , и . „Microservice“ architektūra yra pavyzdinis šiuolaikinio krūvos, įdiegto kiekviena iš minėtų kalbų, pavyzdys.
Atkreipkite dėmesį, kad mes nepropaguojame išimtinai mikropaslaugų. Daugelis iš jūsų dirba su monolitais, kuriuos reikia tobulinti, o kiti – su SOA programomis, kurios plečiasi ir tobulėja, kad taptų mikro paslaugų programomis. Dar kiti pereina prie programų be serverių, o kai kurios diegia pirmiau minėtų dalykų derinius. Straipsnyje išdėstyti principai taikomi kiekvienai iš šių sistemų su tik keliais nedideliais pakeitimais.
Principai
Dabar, kai turime bendrą supratimą apie tai, kas yra moderni programa ir modernus paketas, laikas pasinerti į architektūrą ir kūrimo principus, kurie puikiai pasitarnaus kuriant, diegiant ir prižiūrint modernią programą.
Vienas iš principų skamba kaip „padaryti mažas aplikacijas“, pavadinkime tai mažumo principas. Yra neįtikėtinai sudėtingų programų, kurias sudaro daugybė judančių dalių. Savo ruožtu, sukūrus programą iš mažų, atskirų komponentų, lengviau ją projektuoti, prižiūrėti ir dirbti su ja kaip visuma. (Atkreipkite dėmesį, kad sakėme „supaprastina“, o ne „padaro paprastą“).
Antrasis principas yra tai, kad galime padidinti kūrėjų produktyvumą padėdami jiems sutelkti dėmesį į kuriamas funkcijas, o diegimo metu atlaisvinsime juos nuo infrastruktūros ir CI / CD problemų. Taigi, trumpai, mūsų požiūris orientuota į kūrėjus.
Galiausiai viskas apie jūsų programą turi būti prijungta prie tinklo. Per pastaruosius 20 metų žengėme didelius žingsnius link tinklo ateities, nes tinklai tampa vis greitesni, o programos tampa sudėtingesnės. Kaip jau matėme, šiuolaikišką programą tinkle turi naudoti daugybė skirtingų klientų. Tinklinio mąstymo taikymas architektūrai turi didelių privalumų, kurie puikiai dera mažumo principas ir požiūrio koncepcija, orientuotas į kūrėją.
Jei atsižvelgsite į šiuos principus kurdami ir diegdami programą, turėsite neabejotiną pranašumą kurdami ir pristatydami savo produktą.
Pažvelkime į šiuos tris principus išsamiau.
Mažumo principas
Žmogaus smegenims sunku vienu metu suvokti didelį kiekį informacijos. Psichologijoje kognityvinis krūvis reiškia bendrą protinių pastangų kiekį, reikalingą informacijai išsaugoti atmintyje. Kūrėjų kognityvinės apkrovos mažinimas yra prioritetas, nes tai leidžia jiems sutelkti dėmesį į problemos sprendimą, o ne išlaikyti dabartinį sudėtingą visos programos modelį ir kuriamas funkcijas.
Programos suyra dėl šių priežasčių:
- Sumažėjęs kognityvinis krūvis kūrėjams;
- Testavimo pagreitinimas ir supaprastinimas;
- Greitas aplikacijos pakeitimų pristatymas.
Yra keletas būdų, kaip sumažinti kūrėjų kognityvinį krūvį, ir čia veikia mažumo principas.
Taigi čia yra trys būdai, kaip sumažinti pažinimo krūvį:
- Sutrumpinkite laiką, į kurį jie turi atsižvelgti kurdami naują funkciją – kuo trumpesnis laikotarpis, tuo mažesnė pažinimo apkrova.
- Sumažinkite kodo, su kuriuo atliekamas vienkartinis darbas, kiekį - mažiau kodo - mažiau apkrovos.
- Supaprastinkite laipsniškų programos pakeitimų procesą.
Sutrumpinti kūrimo laiką
Grįžkime į laikus, kai metodika waterfall buvo kūrimo proceso standartas, o programos kūrimo ar atnaujinimo terminai nuo šešių mėnesių iki dvejų metų buvo įprasta praktika. Paprastai inžinieriai pirmiausia perskaito atitinkamus dokumentus, tokius kaip produkto reikalavimai (PRD), sistemos informacinis dokumentas (SRD), architektūros projektas ir pradeda derinti visus šiuos dalykus į vieną pažintinį modelį, pagal kurį jie kodavo. Keičiantis reikalavimams, o kartu ir architektūrai, teko rimtai pasistengti, kad visa komanda būtų informuojama apie pažintinio modelio atnaujinimus. Toks požiūris, blogiausiu atveju, gali tiesiog paralyžiuoti darbą.
Didžiausias pokytis programų kūrimo procese buvo judrios metodikos įdiegimas. Vienas iš pagrindinių metodologijos bruožų agile yra pasikartojantis vystymasis. Savo ruožtu tai sumažina inžinierių pažinimo krūvį. Užuot reikalaudami, kad kūrimo komanda įdiegtų programą per vieną ilgą ciklą, agile Šis metodas leidžia sutelkti dėmesį į nedidelį kodo kiekį, kurį galima greitai išbandyti ir įdiegti, taip pat gauti atsiliepimų. Programos kognityvinė apkrova pasikeitė nuo šešių mėnesių iki dvejų metų, o dviejų savaičių papildymo ar funkcijų pakeitimo specifikacijų yra daug, kad būtų galima neaiškiai suprasti didelę programą.
Didelis pokytis yra perkėlus dėmesį nuo didžiulės programos prie konkrečių mažų funkcijų, kurias galima užbaigti per dviejų savaičių sprintą, turint omenyje ne daugiau kaip vieną funkciją prieš kitą sprintą. Tai leido mums padidinti plėtros produktyvumą, kartu sumažinant pažinimo krūvį, kuris nuolat svyravo.
Metodologijoje agile Tikimasi, kad galutinė programa bus šiek tiek pakeista pradinės koncepcijos versija, todėl galutinis kūrimo taškas būtinai yra dviprasmiškas. Tik kiekvieno konkretaus sprinto rezultatai gali būti aiškūs ir tikslūs.
Mažos kodų bazės
Kitas žingsnis mažinant pažinimo apkrovą yra kodo bazės sumažinimas. Paprastai šiuolaikinės programos yra didžiulės – tvirtą, įmonės programą gali sudaryti tūkstančiai failų ir šimtai tūkstančių kodo eilučių. Priklausomai nuo to, kaip failai sutvarkyti, kodo ir failų sąsajos ir priklausomybės gali būti akivaizdžios arba atvirkščiai. Netgi pats derinimo kodo vykdymas gali būti problemiškas, atsižvelgiant į naudojamas bibliotekas ir tai, kaip gerai derinimo įrankiai atskiria bibliotekas / paketus / modulius ir pasirinktinį kodą.
Programos kodo veikiančio psichikos modelio sukūrimas gali užtrukti įspūdingai daug laiko ir vėl užkrauti didelę pažinimo naštą kūrėjui. Tai ypač pasakytina apie monolitines kodų bazes, kur yra daug kodo, kurio funkcinių komponentų sąveika nėra aiškiai apibrėžta, o dėmesio objektų atskyrimas dažnai būna neryškus, nes nepaisoma funkcinių ribų.
Vienas iš veiksmingų būdų sumažinti inžinierių kognityvinę apkrovą yra pereiti prie mikro paslaugų architektūros. Taikant mikropaslaugų metodą, kiekviena paslauga sutelkia dėmesį į vieną funkcijų rinkinį; tuo tarpu paslaugos prasmė paprastai yra apibrėžta ir suprantama. Paslaugos ribos taip pat aiškios – atminkite, kad komunikacija su paslauga vyksta per API, todėl vienos paslaugos sugeneruoti duomenys gali būti lengvai perduodami kitai.
Sąveika su kitomis paslaugomis paprastai apsiriboja keliomis vartotojų paslaugomis ir keliomis teikėjo paslaugomis, naudojančiomis paprastus ir švarius API skambučius, pvz., naudojant REST. Tai reiškia, kad inžinieriaus pažinimo apkrova labai sumažėja. Didžiausias iššūkis išlieka suprasti paslaugų sąveikos modelį ir tai, kaip tokie dalykai kaip operacijos vyksta keliose paslaugose. Dėl to mikropaslaugų naudojimas sumažina kognityvinį krūvį, nes sumažina kodo kiekį, apibrėžia aiškias paslaugų ribas ir suteikia supratimą apie vartotojų ir tiekėjų santykius.
Maži laipsniški pokyčiai
Paskutinis principo elementas mažumą yra pokyčių valdymas. Kūrėjams kyla ypatinga pagunda pažvelgti į kodo bazę (net galbūt į savo, senesnį kodą) ir pasakyti: „Tai yra šūdas, turime viską perrašyti“. Kartais tai yra teisingas sprendimas, o kartais ne. Tai užkrauna pasaulinio modelio keitimo naštą kūrėjų komandai, o tai savo ruožtu sukelia didžiulę pažinimo apkrovą. Inžinieriams geriau sutelkti dėmesį į pokyčius, kuriuos jie gali atlikti sprinto metu, kad jie galėtų laiku, nors ir palaipsniui, įdiegti reikiamas funkcijas. Galutinis produktas turėtų būti panašus į iš anksto suplanuotą, tačiau su tam tikrais pakeitimais ir bandymais, kad atitiktų kliento poreikius.
Perrašant dideles kodo dalis, kartais neįmanoma greitai pateikti pakeitimų, nes atsiranda kitos sistemos priklausomybės. Norėdami valdyti pakeitimų srautą, galite naudoti funkcijų slėpimą. Iš principo tai reiškia, kad funkcionalumas yra gamyboje, tačiau jis nepasiekiamas naudojant aplinkos kintamojo nustatymus (env-var) ar kokį kitą konfigūravimo mechanizmą. Jei kodas praėjo visus kokybės kontrolės procesus, jis gali būti gaminamas latentinėje būsenoje. Tačiau ši strategija veikia tik tada, kai funkcija galiausiai įjungta. Priešingu atveju tai tik sugadins kodą ir pridės pažinimo krūvį, su kuriuo kūrėjas turės susidoroti, kad būtų produktyvus. Patys pokyčių valdymas ir laipsniški pakeitimai padeda išlaikyti kūrėjų pažintinį krūvį prieinamu lygiu.
Inžinieriai turi įveikti daugybę sunkumų net paprasčiausiai įdiegę papildomas funkcijas. Iš vadovybės būtų protinga sumažinti nereikalingą naštą komandai, kad ji galėtų sutelkti dėmesį į pagrindinius funkcinius elementus. Yra trys dalykai, kuriuos galite padaryti, kad padėtumėte savo kūrimo komandai:
- Naudokite metodiką
agileapriboti laiką, per kurį komanda turi sutelkti dėmesį į pagrindines savybes. - Įdiekite savo programą kaip kelias mikropaslaugas. Tai apribos funkcijų, kurias galima įdiegti, skaičių ir sustiprins ribas, kurios išlaiko pažinimo krūvį darbe.
- Pirmenybę teikite laipsniškiems pakeitimams, o ne dideliems ir sudėtingiems, keiskite mažas kodo dalis. Naudokite funkcijų slėpimą, kad įgyvendintumėte pakeitimus, net jei jie nebus matomi iškart po jų pridėjimo.
Jei savo darbe taikysite smulkumo principą, jūsų komanda bus daug laimingesnė, geriau susikoncentravusi į reikiamų funkcijų įgyvendinimą ir greičiau išvys kokybinius pokyčius. Bet tai nereiškia, kad darbas negali tapti sudėtingesnis, kartais, atvirkščiai, naujo funkcionalumo įdiegimas reikalauja kelių paslaugų modifikavimo, o šis procesas gali būti sunkesnis nei panašus monolitinėje architektūroje. Bet kokiu atveju mažumo metodo privalumai yra verti.
Pirmos dalies pabaiga.
Netrukus publikuosime antrąją vertimo dalį, o dabar laukiame Jūsų komentarų ir kviečiame tai padaryti , kuris vyks šiandien 20.00 val.
Šaltinis: www.habr.com