Hei ystävät. Kurssin alkamista odotellessa , jaa perinteisesti kanssasi hyödyllisen materiaalin käännökset.
Ohjelmistot ratkaisevat yhä enemmän jokapäiväisiä tehtäviä, samalla kun ne muuttuvat yhä monimutkaisemmiksi. Kuten Marc Andressen kerran sanoi, se kuluttaa maailman.
Tämän seurauksena tapa, jolla sovelluksia kehitetään ja toimitetaan, on muuttunut dramaattisesti muutaman viime vuoden aikana. Nämä olivat tektonisen mittakaavan siirtymiä, jotka johtivat joukkoon periaatteita. Nämä periaatteet ovat osoittautuneet hyödyllisiksi tiimin rakentamisessa, suunnittelussa, kehittämisessä ja sovelluksesi toimittamisessa loppukäyttäjille.
Periaatteet voidaan tiivistää seuraavasti: Sovelluksen tulee olla pieni, verkkopohjainen ja sen arkkitehtuuri on kehittäjäkeskeinen. Nämä kolme periaatetta ajatellen voit luoda vankan, päästä päähän -sovelluksen, joka voidaan toimittaa nopeasti ja turvallisesti loppukäyttäjälle ja joka on helposti skaalautuva ja laajennettavissa.
Jokaisessa ehdotetuista periaatteista on useita näkökohtia, joista keskustelemme osoittaaksemme, kuinka kukin periaate edistää perimmäistä tavoitetta, joka on luotettavien sovellusten nopea toimitus, joita on helppo ylläpitää ja käyttää. Tarkastelemme periaatteita suhteessa niiden vastakohtiin selventääksemme, mitä se tarkoittaa, sano: "Varmista, että käytät pienuusperiaate'.
Toivomme, että tämä artikkeli rohkaisee sinua käyttämään ehdotettuja periaatteita nykyaikaisten sovellusten rakentamiseen, mikä tarjoaa yhtenäisen lähestymistavan suunnitteluun jatkuvasti kasvavan teknologiapinon yhteydessä.
Soveltamalla näitä periaatteita huomaat hyödyntäväsi ohjelmistokehityksen uusimpia trendejä, mukaan lukien sovellusten kehittämiseen ja toimittamiseen, säiliöiden käyttöön (esim. ) ja kontin orkestrointikehykset (esim. ), mikropalvelujen käyttö (mukaan lukien Microservice Architecture и mikropalvelusovelluksiin.
Mikä on moderni sovellus?
Nykyaikaiset sovellukset? Moderni pino? Mitä "moderni" tarkalleen ottaen tarkoittaa?
Useimmilla kehittäjillä on vain yleinen käsitys siitä, mistä nykyaikainen sovellus koostuu, joten tämä käsite on määriteltävä selkeästi.
Nykyaikainen sovellus tukee useita asiakkaita, olipa kyseessä sitten React JavaScript -kirjaston käyttöliittymä, Android- tai iOS-mobiilisovellus tai sovellus, joka muodostaa yhteyden toiseen sovellusliittymään. Nykyaikainen sovellus tarkoittaa määräämättömän määrän asiakkaita, joille se tarjoaa tietoja tai palveluita.
Nykyaikainen sovellus tarjoaa API:n, jolla pääset käsiksi pyydettyihin tietoihin ja palveluihin. API:n tulee olla muuttumaton ja vakio, eikä sitä saa kirjoittaa nimenomaan tietyn asiakkaan tiettyä pyyntöä varten. API on saatavilla HTTP(S):n kautta ja tarjoaa pääsyn kaikkiin GUI:n tai CLI:n toimintoihin.
Tietojen on oltava saatavilla yleisesti hyväksytyssä, yhteentoimivassa muodossa, kuten JSON. API paljastaa objektit ja palvelut puhtaalla, organisoidulla tavalla, kuten RESTful API tai GraphQL tarjoavat kunnollisen käyttöliittymän.
Nykyaikaiset sovellukset rakennetaan nykyaikaiselle pinolle, ja moderni pino on vastaavasti pino, joka tukee tällaisia sovelluksia. Tämän pinon avulla kehittäjä voi helposti luoda sovelluksen, jossa on HTTP-liittymä ja selkeät API-päätepisteet. Valitun lähestymistavan avulla sovelluksesi voi helposti vastaanottaa ja lähettää tietoja JSON-muodossa. Toisin sanoen moderni pino vastaa Twelve-Factor -sovelluksen elementtejä .
Tämän tyyppisen pinon suositut versiot perustuvat , , , , и . Mikropalveluarkkitehtuuri edustaa esimerkkiä modernista pinosta, joka on toteutettu kaikilla mainituilla kielillä.
Huomaa, että emme kannata yksinomaan mikropalvelulähestymistapaa. Monet teistä työskentelevät monoliittien kanssa, joita on kehitettävä, kun taas toiset käsittelevät SOA-sovelluksia, jotka laajenevat ja kehittyvät mikropalvelusovelluksiksi. Toiset taas ovat siirtymässä kohti palvelimettomia sovelluksia, ja jotkut toteuttavat yhdistelmiä yllä olevista. Artikkelissa esitetyt periaatteet koskevat jokaista näistä järjestelmistä vain muutamin pienin muutoksin.
Periaatteet
Nyt kun meillä on yhteinen käsitys siitä, mitä moderni sovellus ja moderni pino ovat, on aika sukeltaa arkkitehtuuriin ja kehitysperiaatteisiin, jotka palvelevat sinua hyvin nykyaikaisen sovelluksen kehittämisessä, toteutuksessa ja ylläpidossa.
Yksi periaatteista kuulostaa "tehdä pieniä sovelluksia", kutsutaan sitä vain pienuusperiaate. On olemassa uskomattoman monimutkaisia sovelluksia, jotka koostuvat monista liikkuvista osista. Sovelluksen rakentaminen pienistä, erillisistä komponenteista puolestaan helpottaa sen suunnittelua, ylläpitoa ja työskentelyä kokonaisuutena. (Huomaa, että sanoimme "yksinkertaistaa" ei "tekee yksinkertaiseksi").
Toinen periaate on, että voimme lisätä kehittäjien tuottavuutta auttamalla heitä keskittymään kehittämiinsä ominaisuuksiin ja vapauttamaan heidät infrastruktuurista ja CI/CD-ongelmista toteutuksen aikana. Eli pähkinänkuoressa lähestymistapamme keskittynyt kehittäjiin.
Lopuksi kaiken sovellukseesi liittyvän on oltava yhteydessä verkkoon. Viimeisten 20 vuoden aikana olemme ottaneet suuria harppauksia kohti verkottunutta tulevaisuutta, kun verkot ovat nopeutuneet ja sovellukset monimutkaistuneet. Kuten olemme jo nähneet, nykyaikaista sovellusta on käytettävä verkon yli useiden eri asiakkaiden toimesta. Verkkoajattelun soveltamisella arkkitehtuuriin on merkittäviä etuja, jotka sopivat hyvin yhteen pienuusperiaate ja lähestymistavan käsite, kehittäjäsuuntautunut.
Jos pidät nämä periaatteet mielessä sovellusta suunniteltaessa ja toteuttaessasi, sinulla on kiistaton etu tuotteesi kehittämisessä ja toimittamisessa.
Katsotaanpa näitä kolmea periaatetta tarkemmin.
pienuusperiaate
Ihmisaivojen on vaikea havaita suurta määrää tietoa samanaikaisesti. Psykologiassa termi kognitiivinen kuormitus viittaa siihen henkisen ponnistelun kokonaismäärään, joka tarvitaan tiedon säilyttämiseen muistissa. Kehittäjien kognitiivisen kuormituksen vähentäminen on etusijalla, koska se antaa heille mahdollisuuden keskittyä ongelman ratkaisemiseen sen sijaan, että he säilyttäisivät koko sovelluksen ja kehitettävien ominaisuuksien nykyisen monimutkaisen mallin.
Sovellukset hajoavat seuraavista syistä:
- Vähentynyt kognitiivinen kuormitus kehittäjille;
- Testauksen nopeuttaminen ja yksinkertaistaminen;
- Sovelluksen muutosten nopea toimitus.
On olemassa useita tapoja vähentää kehittäjien kognitiivista kuormitusta, ja tässä tulee esiin pienuuden periaate.
Joten tässä on kolme tapaa vähentää kognitiivista kuormitusta:
- Lyhennä aikaa, joka heidän on otettava huomioon kehittäessään uutta ominaisuutta – mitä lyhyempi aikakehys, sitä pienempi kognitiivinen kuormitus.
- Vähennä koodin määrää, jolla kertatyötä tehdään - vähemmän koodia - vähemmän kuormaa.
- Yksinkertaista vaiheittaisten muutosten tekeminen sovellukseen.
Kehittämisajan lyhentäminen
Palataanpa aikoihin, jolloin menetelmät waterfall oli kehitysprosessin standardi, ja kuudesta kuukaudesta kahteen vuoteen sovelluksen kehittämisen tai päivittämisen aikarajat olivat yleinen käytäntö. Tyypillisesti insinöörit lukevat ensin asiaankuuluvat asiakirjat, kuten tuotevaatimukset (PRD), järjestelmän viiteasiakirjan (SRD), arkkitehtuurisuunnitelman ja alkavat yhdistää kaikkia näitä asioita yhteen kognitiiviseen malliin, jonka mukaan he koodasivat. Vaatimusten ja sitä myötä arkkitehtuurin muuttuessa jouduttiin ponnistelemaan vakavasti koko tiimin tiedottamiseksi kognitiivisen mallin päivityksistä. Tällainen lähestymistapa voisi pahimmillaan yksinkertaisesti halvaannuttaa työn.
Suurin muutos sovelluskehitysprosessissa oli ketterän metodologian käyttöönotto. Yksi menetelmän pääpiirteistä agile on iteratiivinen kehitys. Tämä puolestaan johtaa insinöörien kognitiivisen kuormituksen vähenemiseen. Sen sijaan, että kehitystiimi vaatisi sovelluksen toteuttamista yhdessä pitkässä jaksossa, agile Lähestymistavan avulla voit keskittyä pieniin koodimääriin, jotka voidaan nopeasti testata ja ottaa käyttöön, ja samalla voit saada palautetta. Sovelluksen kognitiivinen kuormitus on siirtynyt kuudesta kuukaudesta kahteen vuoteen, ja siinä on valtava määrä teknisiä tietoja kahden viikon lisäykseen tai ominaisuusmuutokseen, joka kohdistaa suuren sovelluksen hämärämpään ymmärtämiseen.
Painopisteen siirtäminen massiivisesta sovelluksesta tiettyihin pieniin ominaisuuksiin, jotka voidaan suorittaa kahden viikon sprintissä, kun mielessä on vain yksi ominaisuus ennen seuraavaa sprinttiä, on merkittävä muutos. Tämä mahdollisti kehitystyön tuottavuuden lisäämisen ja samalla pienensi jatkuvasti vaihtelevaa kognitiivista kuormitusta.
Metodologiassa agile lopullisen sovelluksen odotetaan olevan hieman muokattu versio alkuperäisestä konseptista, joten kehityksen loppupiste on välttämättä epäselvä. Vain kunkin tietyn sprintin tulokset voivat olla selkeitä ja tarkkoja.
Pienet koodikannat
Seuraava askel kognitiivisen kuormituksen vähentämisessä on koodipohjan vähentäminen. Nykyaikaiset sovellukset ovat pääsääntöisesti massiivisia - vankka yrityssovellus voi koostua tuhansista tiedostoista ja sadoista tuhansista koodiriveistä. Riippuen siitä, miten tiedostot on järjestetty, koodin ja tiedostojen väliset linkit ja riippuvuudet voivat olla ilmeisiä tai päinvastoin. Jopa itse virheenkorjauskoodin suorittaminen voi olla ongelmallista riippuen käytetyistä kirjastoista ja siitä, kuinka hyvin virheenkorjaustyökalut erottavat kirjastot/paketit/moduulit ja mukautetun koodin.
Sovelluksen koodin toimivan mentaalisen mallin rakentaminen voi viedä vaikuttavan ajan, ja jälleen kerran asettaa kehittäjälle suuren kognitiivisen taakan. Tämä pätee erityisesti monoliittisiin koodikantoihin, joissa on paljon koodia, jonka toiminnallisten komponenttien välinen vuorovaikutus ei ole selkeästi määritelty, ja huomion kohteiden erottelu on usein hämärtynyt, koska toiminnallisia rajoja ei kunnioiteta.
Yksi tehokkaista tavoista vähentää insinöörien kognitiivista kuormitusta on siirtyä mikropalveluarkkitehtuuriin. Mikropalvelulähestymistavassa jokainen palvelu keskittyy yhteen ominaisuuksien joukkoon; kun taas palvelun merkitys on yleensä määritelty ja ymmärrettävä. Palvelun rajat ovat myös selvät - muista, että kommunikointi palvelun kanssa tapahtuu API:n kautta, joten yhden palvelun tuottamat tiedot voidaan helposti siirtää toiseen.
Vuorovaikutus muiden palvelujen kanssa rajoittuu yleensä muutamaan käyttäjäpalveluihin ja muutamaan palveluntarjoajapalveluun, jotka käyttävät yksinkertaisia ja puhtaita API-kutsuja, kuten REST-toimintoa. Tämä tarkoittaa, että insinöörin kognitiivinen kuormitus vähenee huomattavasti. Suurin haaste on edelleen ymmärtää palveluiden vuorovaikutusmallia ja sitä, kuinka asiat, kuten tapahtumat, tapahtuvat useissa palveluissa. Tämän seurauksena mikropalveluiden käyttö vähentää kognitiivista kuormitusta vähentämällä koodin määrää, määrittelemällä selkeät palvelurajat ja antamalla ymmärrystä käyttäjien ja palveluntarjoajien välisestä suhteesta.
Pienet asteittaiset muutokset
Periaatteen viimeinen elementti pienuus on muutoksen hallinta. Kehittäjille on erityinen houkutus katsoa koodipohjaa (jopa ehkä omaa, vanhempaa koodiaan) ja sanoa: "Tämä on paskaa, meidän on kirjoitettava kaikki uudelleen." Joskus tämä on oikea päätös, joskus ei. Se asettaa globaalin mallinmuutoksen taakan kehitystiimille, mikä puolestaan johtaa massiiviseen kognitiiviseen kuormitukseen. Insinöörien on parempi keskittyä niihin muutoksiin, joita he voivat tehdä sprintin aikana, jotta he voivat ottaa tarvittavat toiminnot käyttöön ajoissa, vaikkakin vähitellen. Lopputuotteen tulee muistuttaa ennalta suunniteltua, mutta asiakkaan tarpeiden mukaisin muokkauksin ja testauksin.
Kun suuria osia koodia kirjoitetaan uudelleen, muutosta ei joskus ole mahdollista toimittaa nopeasti, koska muut järjestelmäriippuvuudet tulevat peliin. Voit hallita muutoskulkua käyttämällä ominaisuuden piilottamista. Periaatteessa tämä tarkoittaa, että toiminnallisuus on tuotannossa, mutta se ei ole käytettävissä ympäristömuuttujan asetuksilla (env-var) tai jollain muulla konfigurointimekanismilla. Jos koodi on läpäissyt kaikki laadunvalvontaprosessit, se voi päätyä tuotantoon piilevässä tilassa. Tämä strategia toimii kuitenkin vain, jos ominaisuus otetaan lopulta käyttöön. Muuten se vain sotkee koodia ja lisää kognitiivista kuormaa, jota kehittäjän on käsiteltävä ollakseen tuottava. Muutoksenhallinta ja inkrementaaliset muutokset auttavat pitämään kehittäjien kognitiivisen kuormituksen kohtuullisella tasolla.
Insinöörien on voitettava monia vaikeuksia jopa yksinkertaisella lisätoimintojen käyttöönotolla. Johdon puolelta olisi järkevää vähentää tiimin tarpeetonta taakkaa, jotta se voi keskittyä tärkeimpiin toiminnallisiin elementteihin. Voit auttaa kehitystiimiäsi kolmella tavalla:
- Käytä metodologiaa
agilerajoittaa aikaväliä, jonka kuluessa joukkueen on keskityttävä avainominaisuuksiin. - Toteuta sovelluksesi useana mikropalveluna. Tämä rajoittaa toteutettavissa olevien ominaisuuksien määrää ja vahvistaa rajoja, jotka pitävät kognitiivisen kuormituksen toiminnassa.
- Suosi vähitellen muutoksia suuriin ja raskaisiin, vaihda pieniä koodinpätkiä. Käytä ominaisuuden piilottamista muutosten toteuttamiseen, vaikka ne eivät olisikaan näkyvissä heti lisäämisen jälkeen.
Jos noudatat työssäsi pienuuden periaatetta, tiimisi on paljon onnellisempi, keskittyy paremmin tarvittavien ominaisuuksien toteuttamiseen ja todennäköisemmin toteuttaa laadullisia muutoksia nopeammin. Mutta tämä ei tarkoita sitä, etteikö työ voisi muuttua monimutkaisemmaksi, joskus päinvastoin uuden toiminnallisuuden käyttöönotto vaatii useiden palvelujen muokkaamista, ja tämä prosessi voi olla vaikeampaa kuin vastaava monoliittisessa arkkitehtuurissa. Joka tapauksessa pienimuotoisen lähestymistavan edut ovat sen arvoisia.
Ensimmäisen osan loppu.
Pian julkaisemme käännöksen toisen osan, ja nyt odotamme kommenttejasi ja kutsumme sinut siihen , joka järjestetään tänään klo 20.00.
Lähde: will.com