Tere, sõbrad. Kursuse käivitamise ootuses , jagage teiega traditsiooniliselt kasuliku materjali tõlget.
Tarkvara lahendab üha rohkem igapäevaseid ülesandeid, muutudes samal ajal üha keerulisemaks. Nagu Marc Andressen kunagi ütles, kulutab see maailma.
Selle tulemusena on rakenduste arendamise ja tarnimise viis viimastel aastatel dramaatiliselt muutunud. Need olid tektoonilise skaala nihked, mille tulemuseks oli põhimõtete kogum. Need põhimõtted on osutunud abiks teie rakenduse meeskonna loomisel, kavandamisel, arendamisel ja lõppkasutajatele edastamisel.
Põhimõtted võib kokku võtta järgmiselt: rakendus peaks olema väike, veebipõhine ja arendajakeskse arhitektuuriga. Neid kolme põhimõtet silmas pidades saate luua tugeva ja tervikliku rakenduse, mida saab kiiresti ja turvaliselt lõppkasutajale edastada ning mis on kergesti skaleeritav ja laiendatav.
Igal väljapakutud põhimõttel on mitmeid aspekte, mida arutame, et näidata, kuidas iga põhimõte aitab kaasa lõppeesmärgi saavutamisele, milleks on usaldusväärsete rakenduste kiire tarnimine, mida on lihtne hooldada ja kasutada. Vaatleme põhimõtteid seoses nende vastanditega, et selgitada, mida see tähendab, öelge: "Kasutate kindlasti väiksuse põhimõte'.
Loodame, et see artikkel julgustab teid kasutama väljapakutud põhimõtteid kaasaegsete rakenduste loomiseks, mis pakuvad ühtset lähenemisviisi disainile üha kasvava tehnoloogiavirna kontekstis.
Neid põhimõtteid rakendades leiate end kasutamast tarkvaraarenduse uusimaid suundumusi, sealhulgas rakenduste arendamiseks ja tarnimiseks, konteinerite kasutamiseks (näiteks ) ja konteinerite orkestreerimisraamistikud (näiteks ), mikroteenuste (sh Microservice Architecture) kasutamine и mikroteenuste rakenduste jaoks.
Mis on kaasaegne rakendus?
Kaasaegsed rakendused? Kaasaegne virn? Mida täpselt tähendab "kaasaegne"?
Enamikul arendajatest on ainult üldine ettekujutus sellest, millest moodne rakendus koosneb, seega on vaja see mõiste selgelt määratleda.
Kaasaegne rakendus toetab mitut klienti, olgu selleks siis React JavaScripti teegi kasutajaliides, Androidi või iOS-i mobiilirakendus või rakendus, mis loob ühenduse mõne muu API-ga. Kaasaegne rakendus eeldab määramatut arvu kliente, kellele see andmeid või teenuseid pakub.
Kaasaegne rakendus pakub API-d, et pääseda juurde soovitud andmetele ja teenustele. API peaks olema muutumatu ja püsiv ning mitte kirjutatud konkreetse kliendi konkreetse päringu jaoks. API on saadaval HTTP(S) kaudu ja annab juurdepääsu kõigile GUI-s või CLI-s saadaolevatele funktsioonidele.
Andmed peavad olema kättesaadavad üldtunnustatud koostalitlusvõimelises vormingus (nt JSON). API paljastab objektid ja teenused puhtal ja organiseeritud viisil, näiteks RESTful API või GraphQL pakuvad korralikku liidest.
Kaasaegsed rakendused on üles ehitatud moodsale pinule ja kaasaegne virn on vastavalt virn, mis selliseid rakendusi toetab. See virn võimaldab arendajal hõlpsalt luua HTTP-liidese ja selgete API lõpp-punktidega rakendust. Valitud lähenemisviis võimaldab teie rakendusel hõlpsasti andmeid JSON-vormingus vastu võtta ja saata. Teisisõnu, tänapäevane virn vastab kaheteistkümne teguri rakenduse elementidele .
Seda tüüpi virna populaarsed versioonid põhinevad , , , , и . Mikroteenuste arhitektuur on näide kaasaegsest virust, mis on rakendatud kõigis mainitud keeltes.
Pange tähele, et me ei poolda ainult mikroteenuste lähenemisviisi. Paljud teist töötavad monoliitidega, mis peavad arenema, samas kui teised tegelevad SOA-rakendustega, mis laienevad ja arenevad mikroteenuste rakendusteks. Teised aga liiguvad serverita rakenduste poole ja mõned rakendavad ülalnimetatute kombinatsioone. Artiklis kirjeldatud põhimõtted kehtivad kõigi nende süsteemide puhul vaid mõne väiksema muudatusega.
Põhimõtted
Nüüd, kui meil on ühine arusaam sellest, mis on kaasaegne rakendus ja kaasaegne pinu, on aeg sukelduda arhitektuuri ja arenduspõhimõtetesse, mis aitavad teid hästi kaasaegse rakenduse arendamisel, juurutamisel ja hooldamisel.
Üks põhimõtetest kõlab nagu "teha väikseid rakendusi", nimetagem seda lihtsalt väiksuse põhimõte. On uskumatult keerulisi rakendusi, mis koosnevad paljudest liikuvatest osadest. Rakenduse koostamine väikestest diskreetsetest komponentidest omakorda muudab selle kujundamise, hooldamise ja tervikuna töötamise lihtsamaks. (Pange tähele, et me ütlesime "lihtsustab", mitte "teeb lihtsaks").
Teine põhimõte on see, et saame arendaja tootlikkust suurendada, aidates neil keskenduda arendatavatele funktsioonidele, vabastades nad juurutamise ajal infrastruktuuri ja CI/CD probleemidest. Niisiis, lühidalt meie lähenemine keskendunud arendajatele.
Lõpuks peab kõik teie rakendusega seotud olema võrguga ühendatud. Viimase 20 aasta jooksul oleme teinud suuri edusamme võrgustatud tuleviku suunas, kuna võrgud muutuvad kiiremaks ja rakendused keerukamaks. Nagu nägime, peavad moodsat rakendust üle võrgu kasutama paljud erinevad kliendid. Võrgumõtte rakendamisel arhitektuurile on olulisi eeliseid, mis sobivad hästi kokku väiksuse põhimõte ja lähenemisviisi kontseptsioon, arendajale orienteeritud.
Kui te neid põhimõtteid rakenduse kavandamisel ja juurutamisel silmas peate, saate oma toote arendamisel ja tarnimisel vaieldamatu eelise.
Vaatame neid kolme põhimõtet üksikasjalikumalt.
väiksuse põhimõte
Inimese ajul on raske korraga tajuda suurt hulka informatsiooni. Psühholoogias viitab mõiste kognitiivne koormus kogu vaimsele pingutusele, mis on vajalik teabe säilitamiseks mälus. Arendajate kognitiivse koormuse vähendamine on prioriteet, sest see võimaldab neil keskenduda probleemi lahendamisele, selle asemel, et hoida peas kogu rakenduse praegust keerulist mudelit ja arendatavaid funktsioone.
Rakendused lagunevad järgmistel põhjustel:
- Vähendatud kognitiivne koormus arendajatele;
- Testimise kiirendamine ja lihtsustamine;
- Rakenduse muudatuste kiire kohaletoimetamine.
Arendajate kognitiivse koormuse vähendamiseks on mitu võimalust ja siin tulebki mängu väiksuse põhimõte.
Siin on kolm võimalust kognitiivse koormuse vähendamiseks:
- Vähendage ajavahemikku, millega nad peavad arvestama uue funktsiooni väljatöötamisel – mida lühem on ajavahemik, seda väiksem on kognitiivne koormus.
- Vähendage ühekordse töö tegemise koodi hulka - vähem koodi - vähem koormust.
- Lihtsustage rakenduses järkjärguliste muudatuste tegemise protsessi.
Arendusaja lühendamine
Tuleme tagasi aegadesse, mil metoodika waterfall oli arendusprotsessi standard ja kuue kuu kuni kahe aasta pikkused tähtajad rakenduse arendamiseks või värskendamiseks olid tavapärased. Tavaliselt loevad insenerid esmalt asjakohaseid dokumente, nagu tootenõuded (PRD), süsteemi viitedokument (SRD), arhitektuuriplaani ja hakkavad kõiki neid asju kombineerima üheks kognitiivseks mudeliks, mille järgi nad kodeerisid. Kuna nõuded ja sellest tulenevalt ka arhitektuur muutusid, tuli tõsiselt pingutada, et kogu meeskonda kognitiivse mudeli uuendustest teavitada. Selline lähenemine võib halvimal juhul lihtsalt töö halvata.
Suurim muudatus rakenduste arendusprotsessis oli agiilse metoodika kasutuselevõtt. Üks metoodika põhijooni agile on iteratiivne arendus. See omakorda toob kaasa inseneride kognitiivse koormuse vähenemise. Selle asemel, et nõuda arendusmeeskonnalt rakenduse juurutamist ühe pika tsükli jooksul, agile lähenemine võimaldab keskenduda väikestele koodikogustele, mida saab kiiresti testida ja juurutada, saades samal ajal ka tagasisidet. Rakenduse kognitiivne koormus on nihkunud kuuekuuselt kaheaastasele ajaraamile, kusjuures kahenädalaseks lisamiseks või funktsioonide muudatuseks on tohutul hulgal spetsifikatsioone, mis on suunatud suure rakenduse hägusemale mõistmisele.
Fookuse nihutamine massiivselt rakenduselt konkreetsetele väikestele funktsioonidele, mida saab lõpetada kahenädalase sprindi jooksul, pidades silmas mitte rohkem kui ühte funktsiooni enne järgmist sprindi, on oluline muutus. See võimaldas meil tõsta arendustootlikkust, vähendades samal ajal kognitiivset koormust, mis pidevalt kõikus.
Metoodikas agile lõplik rakendus peaks olema algse kontseptsiooni veidi muudetud versioon, seega on arenduse lõpp-punkt tingimata mitmetähenduslik. Ainult iga konkreetse sprindi tulemused võivad olla selged ja täpsed.
Väikesed koodibaasid
Järgmine samm kognitiivse koormuse vähendamisel on koodibaasi vähendamine. Kaasaegsed rakendused on reeglina massilised – robustne ettevõtterakendus võib koosneda tuhandetest failidest ja sadadest tuhandetest koodiridadest. Sõltuvalt failide korraldamisest võivad koodi ja failide vahelised lingid ja sõltuvused olla ilmsed või vastupidi. Isegi silumiskoodi täitmine ise võib olla problemaatiline, olenevalt kasutatavatest teekidest ja sellest, kui hästi silumistööriistad teeke/pakette/mooduleid ja kohandatud koodi eristavad.
Rakenduse koodi toimiva vaimse mudeli loomine võib võtta muljetavaldavalt palju aega ja asetada arendajale taas suure kognitiivse koormuse. See kehtib eriti monoliitsete koodialuste kohta, kus on suur hulk koodi, mille funktsionaalsete komponentide koostoime ei ole selgelt määratletud ning tähelepanuobjektide eraldatus on sageli hägune, kuna ei peeta kinni funktsionaalsetest piiridest.
Üks tõhusamaid viise inseneride kognitiivse koormuse vähendamiseks on mikroteenuste arhitektuurile üleminek. Mikroteenuste lähenemisviisis keskendub iga teenus ühele funktsioonide komplektile; samas kui teenuse tähendus on tavaliselt määratletud ja arusaadav. Teenuse piirid on samuti selged – pidage meeles, et suhtlus teenusega toimub API kaudu, nii et ühe teenuse genereeritud andmeid saab hõlpsasti teisele edastada.
Muude teenustega suhtlemine piirdub tavaliselt mõne kasutajateenuse ja mõne teenusepakkuja teenusega, mis kasutavad lihtsaid ja puhtaid API-kõnesid (nt REST-i kasutamine). See tähendab, et inseneri kognitiivne koormus väheneb tõsiselt. Suurimaks väljakutseks jääb teenuse interaktsiooni mudeli mõistmine ja see, kuidas sellised asjad nagu tehingud mitme teenuse vahel toimuvad. Selle tulemusena vähendab mikroteenuste kasutamine kognitiivset koormust, vähendades koodi hulka, määratledes selged teenusepiirid ning pakkudes arusaama kasutajate ja pakkujate vahelistest suhetest.
Väikesed järkjärgulised muutused
Põhimõtte viimane element väiksus on muudatuste juhtimine. Arendajatel on eriline kiusatus vaadata koodibaasi (isegi võib-olla oma vanemat koodi) ja öelda: "See on jama, me peame selle kõik ümber kirjutama." Mõnikord on see õige otsus ja mõnikord mitte. See paneb arendusmeeskonnale globaalse mudeli muutmise koormuse, mis omakorda toob kaasa tohutu kognitiivse koormuse. Parem on inseneridel keskenduda muudatustele, mida nad saavad sprindi jooksul teha, et nad saaksid vajaliku funktsionaalsuse õigeaegselt, kuigi järk-järgult kasutusele võtta. Lõpptoode peaks sarnanema etteplaneerituga, kuid mõningate muudatuste ja testimisega vastavalt kliendi vajadustele.
Suurte koodiosade ümberkirjutamisel ei ole mõnikord võimalik muudatust kiiresti edastada, kuna mängu tulevad muud süsteemisõltuvused. Muudatuste voo juhtimiseks saate kasutada funktsioonide peitmist. Põhimõtteliselt tähendab see, et funktsionaalsus on küll tootmises, kuid see pole keskkonnamuutuja seadete (env-var) või mõne muu konfiguratsioonimehhanismi abil saadaval. Kui kood on läbinud kõik kvaliteedikontrolli protsessid, võib see jõuda tootmisesse varjatud olekus. See strateegia töötab aga ainult siis, kui funktsioon on lõpuks lubatud. Vastasel juhul ajab see koodi ainult segamini ja lisab kognitiivset koormust, millega arendaja peab produktiivseks tegutsemiseks tegelema. Muudatuste juhtimine ja järkjärgulised muudatused aitavad hoida arendajate kognitiivset koormust taskukohasel tasemel.
Insenerid peavad ületama palju raskusi isegi lisafunktsioonide lihtsa kasutuselevõtuga. Juhtkonna poolt oleks mõistlik vähendada meeskonna tarbetut koormust, et see saaks keskenduda peamistele funktsionaalsetele elementidele. Oma arendusmeeskonna abistamiseks saate teha kolme asja:
- Kasutage metoodikat
agilepiirata ajavahemikku, mille jooksul meeskond peab keskenduma põhifunktsioonidele. - Rakendage oma rakendus mitme mikroteenusena. See piirab rakendatavate funktsioonide arvu ja tugevdab piire, mis hoiavad kognitiivset koormust töös.
- Eelistage järkjärgulisi muudatusi suurtele ja kohmakatele, muutke väikseid kooditükke. Kasutage funktsioonide peitmist muudatuste rakendamiseks isegi siis, kui need pole pärast lisamist kohe nähtavad.
Kui rakendate oma töös väiksuse põhimõtet, on teie meeskond palju õnnelikum, keskendub paremini vajalike funktsioonide juurutamisele ja suudab kvalitatiivseid muudatusi kiiremini ellu viia. Kuid see ei tähenda, et töö ei saaks muutuda keerulisemaks, mõnikord, vastupidi, nõuab uue funktsionaalsuse juurutamine mitme teenuse muutmist ja see protsess võib olla keerulisem kui sarnane monoliitses arhitektuuris. Igal juhul on väiksuse lähenemisviisi eelised seda väärt.
Esimese osa lõpp.
Peagi avaldame tõlke teise osa ja nüüd ootame teie kommentaare ja kutsume teid seda tegema , mis toimub täna kell 20.00.
Allikas: www.habr.com