Ohjelmistosuunnittelun ja arkkitehtuurin oppiminen - tiekartta

Tämä artikkeli on yhteenveto siitä, mistä kirjoitan uusimmassa projektissani, solidbook.io - Handbook to Software Design and Architecture with TypeScript. Katso se, josta pidät tästä viestistä.

Minulle on hullua ajatella, että Facebook oli kerran tyhjä tekstitiedosto jonkun tietokoneessa.

LOL.

Kuluneen vuoden aikana olen työskennellyt kovasti ohjelmistosuunnittelussa ja arkkitehtuurissa, toimialueohjatussa suunnittelussa ja kirjoittanut siihen kirjan, ja halusin hetken yrittää koota sen yhteen hyödylliseksi, jonka voisin jakaa yhteisön kanssa. .

Tässä on etenemissuunnitelmani ohjelmistosuunnittelun ja arkkitehtuurin oppimiseksi.

Olen jakanut sen kahteen esineeseen: pino ja kartta .

Pino

Samanlainen kuin verkottumisessa oleva OSI-malli, jokainen kerros rakentuu edellisen kerroksen päälle.

Pino

Kartta

Vaikka pino on mielestäni hyvä nähdä isompi kuva siitä, miten kaikki toimii yhdessä, kartta on hieman yksityiskohtaisempi (ja innoittamana verkkokehittäjien etenemissuunnitelmasta) ja sen seurauksena mielestäni se on hyödyllisempi.

Tässä se on alla! Haasta repo, lue yksityiskohtainen kirjoitus ja lataa se suurikokoisina, napsauta tätä.

Ohjelmistosuunnittelun ja arkkitehtuurin tiekartta

Vaihe 1: Puhdista koodi

Ensimmäinen askel kohti pitkäikäisten ohjelmistojen luomista on selvittää, kuinka kirjoittaa puhdas koodi .

Puhdas koodi on koodi, joka on helppo ymmärtää ja muuttaa. Alhaisella tasolla tämä ilmenee muutamissa suunnitteluvaihtoehdoissa, kuten:

  • olla johdonmukainen
  • mieluummin mielekkäät muuttujat, menetelmä ja luokan nimet kommenttien kirjoittamisen sijaan
  • varmistamalla, että koodi on sisennetty ja sijoitettu oikein
  • varmistaa, että kaikki testit voidaan suorittaa
  • puhtaiden toimintojen kirjoittaminen ilman sivuvaikutuksia
  • ei läpäise nollaa

Puhtaan koodin kirjoittaminen on uskomattoman tärkeää.

Ajattele sitä kuin jengapeli.

Jotta projektimme rakenne pysyisi vakaana ajan myötä, esimerkiksi sisennykset, pienet luokat ja menetelmät sekä merkitykselliset nimet maksavat paljon pitkällä aikavälillä.

Paras resurssi oppia kirjoittamaan puhdas koodi on setä Bobin kirja "Puhdas koodi".

Vaihe 2: Ohjelmointimallit

Nyt kun kirjoitamme luettavaa koodia, jota on helppo ylläpitää, olisi hyvä ymmärtää todella kolme suurta ohjelmointiparadigmaa ja tapa, jolla ne vaikuttavat koodin kirjoittamiseen.

Bob-setä "Puhdas arkkitehtuuri" -kirjassa hän kiinnittää huomiota siihen, että:

  • Kohdesuuntautunut ohjelmointi on työkalu, joka sopii parhaiten määrittämään kuinka ylitämme arkkitehtoniset rajat polymorfismin ja laajennusten avulla
  • Toiminnallinen ohjelmointi on työkalu, jolla työnnämme tietoja sovelluksemme rajoille
  • ja strukturoitu ohjelmointi on työkalu, jota käytämme algoritmien kirjoittamiseen

Tämä tarkoittaa, että tehokas ohjelmisto käyttää hybridi kaikkia 3 ohjelmointiparatiikkatyyliä eri aikoina.

Vaikka et voisi ottaa tiukasti toiminnallista tai tiukasti olio-lähestymistapa kirjoittaa koodia, ymmärtää missä kukin loistaa parantaa laatua malleja.

Jos sinulla on vain vasara, kaikki näyttää naulalta.

Resurssit

Katso toiminnallinen ohjelmointi :

  • Professori Frisbyn enimmäkseen riittävä opas toiminnalliseen ohjelmointiin
  • Toimialueiden mallinnus on toiminut

Vaihe 3: Olio-ohjelmointi

On tärkeää tietää, miten kukin paradigma toimii ja miten ne kehottavat sinua rakentamaan koodin niiden sisällä, mutta arkkitehtuurin osalta olio-ohjelmointi on selkeä työkalu työhön .

Objektisuuntautunut ohjelmointi ei ainoastaan ​​auta meitä luomaan laajennusarkkitehtuuria ja rakentamaan joustavuutta projekteihimme; OOP: n mukana tulee OOP: n neljä periaatetta (kapselointi, perintö, polymorfismi ja abstraktio), jotka auttavat meitä luomaan rikkaita verkkotunnusmalleja .

Useimmat kehittäjät, jotka oppivat olio-ohjelmointia, eivät koskaan pääse tähän osaan: oppivat luomaan ongelma-alueen ohjelmistototeutuksen ja sijoittamaan sen kerrostetun verkkosovelluksen keskelle .

Toiminnallinen ohjelmointi voi tuntua keinolta tämän skenaarion kaikkien päämäärien saavuttamiseen, mutta suosittelen tutustumista mallipohjaiseen suunnitteluun ja toimialueohjattuun suunnitteluun, jotta ymmärrät suuremman kuvan siitä, kuinka objektimallintajat pystyvät kapseloimaan koko yrityksen nollariippuvuusalueen malli.

Miksi se on valtava kauppa?

Se on valtava, koska jos pystyt luomaan liiketoiminnan henkisen mallin, voit luoda kyseisen yrityksen ohjelmistototeutuksen.

Vaihe 4: Suunnittelun periaatteet

Tässä vaiheessa ymmärrät, että olio-ohjelmointi on erittäin hyödyllistä kapseloimalla rikkaat verkkotunnusmallit ja ratkaistessa 3. tyyppiä "Hard Software Problems" - monimutkaiset verkkotunnukset.

Mutta OOP voi tuoda esiin joitain suunnitteluhaasteita.

Milloin minun pitäisi käyttää sävellystä?

Milloin minun pitäisi käyttää perintöä?

Milloin minun tulisi käyttää abstraktia luokkaa?

Suunnitteluperiaatteet ovat todella vakiintuneita ja taistelutestattuja objektiivisia parhaita käytäntöjä, joita käytät kiskovartijoina.

Joitakin esimerkkejä yleisistä suunnitteluperiaatteista, joihin sinun tulisi tutustua, ovat:

  • Koostumus perinnöstä
  • Kapseloi mikä vaihtelee
  • Ohjaa abstraktioita, ei konkretioita
  • Hollywoodin periaate: "Älä soita meille, soitamme sinulle"
  • SOLID-periaatteet, erityisesti yhden vastuun periaate
  • KUIVA (älä toista itseäsi)
  • YAGNI (et tarvitse sitä)

Varmista kuitenkin, että tulet omiin johtopäätöksiisi. Älä seuraa vain sitä, mitä joku muu sanoo sinun tekevän. Varmista, että sillä on järkevää sinulle.

Vaihe 5: Suunnittelukuviot

Lähes kaikki ohjelmistojen ongelmat on luokiteltu ja ratkaistu jo. Kutsumme näitä malleja: itse asiassa suunnittelumalleja.

Suunnittelumalleja on 3 luokkaa: luova , rakenteellinen ja käyttäytyminen .

Luova

Luovuusmallit ovat malleja, jotka hallitsevat esineiden luomista.

Esimerkkejä luovista malleista ovat:

  • Singleton kuvio , varmistavat, että vain yhden luokan instanssi voi olla
  • Abstract Factory malli , luoda instanssi useita perheitä luokkien
  • Prototype kuvio , aloitusaika ulos esimerkki, joka on kloonattu olemassa olevasta

Rakenteellinen

Rakennemallit ovat malleja, jotka yksinkertaistavat komponenttien välisten suhteiden määrittelyä.

Esimerkkejä rakennesuunnittelumalleista ovat:

  • Adapter malli , luoda rajapinnan avulla luokkia, jotka normaalisti eivät voi työskennellä yhdessä, työskennellä yhdessä.
  • Bridge kuvio , pilkkominen luokka, joka on itse asiassa olla yksi tai useampia, joukoksi luokkia, jotka kuuluvat hierarkian, joka mahdollistaa toteutukset voidaan kehittää toisistaan riippumatta.
  • Decorator kuvio , lisäämällä vastuu esineitä dynaamisesti.

Käyttäytyminen

Käyttäytymismallit ovat yleisiä malleja tyylikkään viestinnän helpottamiseksi esineiden välillä.

Esimerkkejä käyttäytymismalleista ovat:

  • Mallinekuvio , lykätään tarkat vaiheet algoritmin alaluokkaan.
  • Sovittelija kuvio , määrittämiseksi tarkka viestintäkanavien sallittu luokkien välillä.
  • Observer malli , joka mahdollistaa luokkien tilata jotain kiinnostaa, ja saada ilmoituksen, kun muutos on tapahtunut.

Suunnittelukriteerit

Suunnittelumallit ovat hienoja ja kaikki, mutta joskus ne voivat lisätä monimutkaisuutta malleihimme. On tärkeää muistaa YAGNI ja yrittää pitää suunnittelumme mahdollisimman yksinkertaisina. Käytä suunnittelumalleja vain, kun olet todella varma, että tarvitset niitä. Tiedät milloin.

Jos tiedämme, mitä kukin näistä malleista on, milloin niitä tulee käyttää ja milloin ei edes vaivaudu niiden käyttöön, olemme hyvässä kunnossa ymmärtämään, kuinka suunnitella suurempia järjestelmiä.

Syynä tähän on se, että arkkitehtoniset kuviot ovat vain suunnittelumalleja, jotka on räjäytetty mittakaavassa korkealle tasolle , jossa suunnittelumallit ovat matalan tason toteutuksia (lähempänä luokkia ja toimintoja).

Resurssit

Refraktoiva Guru - Suunnittelumallit

Vaihe 6: Arkkitehtoniset periaatteet

Nyt olemme korkeammalla ajattelutasolla kuin luokkataso.

Ymmärrämme nyt, että päätöksillä, jotka tehdään suhteiden rakentamiseksi ja rakentamiseksi komponenttien välillä korkealla ja matalalla tasolla, on merkittävä vaikutus projektimme ylläpidettävyyteen, joustavuuteen ja testattavuuteen.

Opi ohjaavat periaatteet, jotka auttavat sinua rakentamaan joustavuutta, jota koodikanta tarvitsee voidakseen reagoida uusiin ominaisuuksiin ja vaatimuksiin mahdollisimman pienellä vaivalla.

Tässä suosittelen oppimista heti lepakosta:

  • Komponenttien suunnitteluperiaatteet: Stabiili abstraktioperiaate, Stabiili riippuvuusperiaate ja Asyklinen riippuvuusperiaate komponenttien järjestämisestä, niiden riippuvuuksista, milloin pariksi, ja seurauksista vahingossa riippuvuussyklien luomisen ja epävakaiden komponenttien tukemisen perusteella.
  • Käytäntö vs. yksityiskohta, jotta ymmärrät miten sovelluksesi säännöt erotetaan toteutuksen yksityiskohdista.
  • Rajat ja kuinka tunnistaa aliverkkotunnukset, joihin sovelluksesi ominaisuudet kuuluvat.

Bob-setä löysi ja dokumentoi alun perin monia näistä periaatteista, joten paras resurssi oppia tästä on jälleen "puhdas arkkitehtuuri".

Vaihe 7: Arkkitehtoniset tyylit

Arkkitehtuuri koskee tärkeitä asioita.

Kyse on järjestelmän tunnistamisesta, jotta järjestelmä toimisi menestyksekkäästi, ja pinoamalla menestyskerroin valitsemalla arkkitehtuuri, joka parhaiten vastaa vaatimuksia.

Esimerkiksi järjestelmä, jolla on paljon liiketoimintalogiikan monimutkaisuutta , hyötyisi kerrostetun arkkitehtuurin käytöstä tämän monimutkaisuuden kapseloimiseksi.

Uberin kaltaisen järjestelmän on pystyttävä käsittelemään paljon reaaliaikaisia ​​tapahtumia kerralla ja päivittämään ohjainten sijainnit, joten julkaisu-tilaus -tyylinen arkkitehtuuri voi olla tehokkain.

Toistan itseni täällä, koska on tärkeää huomata, että kolme arkkitehtonisen tyylin luokkaa ovat samanlaisia ​​kuin kolme suunnittelumallien luokkaa, koska arkkitehtoniset tyylit ovat korkean tason suunnittelumalleja .

Rakenteellinen

Projektit, joilla on erilainen komponenttitaso ja laaja toiminnallisuus, hyötyvät joko rakenteellisen arkkitehtuurin omaksumisesta tai kärsivät siitä.

Tässä on muutama esimerkki:

  • Komponenttipohjaiset arkkitehtuurit korostavat huolenaiheiden erottamista järjestelmän yksittäisten komponenttien välillä. Ajattele Googlea sekunnin ajan. Mieti, kuinka monta sovellusta heillä on yrityksessään (Google Docs, Google Drive, Google Maps jne.). Paljon toiminnallisilla alustoilla komponenttipohjaiset arkkitehtuurit jakavat huolenaiheet löyhästi kytkettyihin itsenäisiin komponentteihin. Tämä on vaakasuora erotus.
  • Monoliitti tarkoittaa, että sovellus on yhdistetty yhdeksi alustaksi tai ohjelmaksi, joka on otettu käyttöön kokonaan. Huomaa: Sinulla voi olla komponenttipohjainen JA monoliittinen arkkitehtuuri, jos erotat sovelluksesi oikein, mutta kuitenkin otat sen käyttöön yhtenä kokonaisuutena .
  • Kerroksiset arkkitehtuurit erottavat ongelmat vertikaalisesti leikkaamalla ohjelmistot infrastruktuuri-, sovellus- ja verkkotunnuskerroksiin.

Puhdas arkkitehtuuri

Esimerkki sovelluksen ongelmien leikkaamisesta vertikaalisesti käyttämällä kerrostettua arkkitehtuuria. Lue täältä lisätietoja siitä, miten tämä tehdään.

Viestit

Projektistasi riippuen viestit voivat olla todella tärkeä osa järjestelmän menestystä. Tällaisissa projekteissa viestipohjaiset arkkitehtuurit rakentuvat toiminnallisten ohjelmointiperiaatteiden ja käyttäytymissuunnittelumallien, kuten tarkkailijamallin, päälle.

Tässä on muutama esimerkki sanomapohjaisista arkkitehtuurityyleistä:

  • Tapahtumavetoiset arkkitehtuurit katsovat kaikki allekirjoittavat tilan muutokset tapahtumina. Esimerkiksi vinyylikauppasovelluksessa tarjouksen tila voi muuttua "odottavasta" tilaan "hyväksytty", kun molemmat osapuolet ovat sopineet kaupasta.
  • Publish-tilaa -arkkitehtuurit rakentuvat Observer-suunnittelumallin päälle tekemällä siitä ensisijainen viestintämenetelmä järjestelmän, loppukäyttäjien / asiakkaiden ja muiden järjestelmien ja komponenttien välillä.

Hajautettu

Hajautettu arkkitehtuuri tarkoittaa yksinkertaisesti sitä, että järjestelmän komponentit otetaan käyttöön erikseen ja toimivat kommunikoimalla verkkoprotokollan kautta. Hajautetut järjestelmät voivat olla erittäin tehokkaita suorituskyvyn skaalauksessa, joukkueiden skaalauksessa ja (mahdollisesti kalliiden tehtävien tai) vastuun siirtämisessä muille komponenteille.

Muutamia esimerkkejä hajautetuista arkkitehtonisista tyyleistä ovat:

  • Asiakas-palvelin- arkkitehtuuri. Yksi yleisimmistä arkkitehtuureista, jossa jaettavat tehtävät asiakkaan (esitys) ja palvelimen (liiketoimintalogiikka) välillä.
  • Peer-to-peer -arkkitehtuurit jakavat sovellustason tehtävät tasa-arvoisten osallistujien kesken muodostaen vertaisverkon.

Vaihe 8: Arkkitehtoniset kuviot

Arkkitehtoniset kuviot selittävät taktisesti yksityiskohtaisemmin, miten yksi näistä arkkitehtonisista tyyleistä todella toteutetaan .

Tässä on muutama esimerkki arkkitehtonisista kuvioista ja tyyleistä, joista ne perivät:

  • Domain-Driven Design on lähestymistapa ohjelmistokehitykseen todella monimutkaisten ongelma-alueiden kanssa. Jotta DDD olisi menestyksekkäin, meidän on toteutettava kerrostettu arkkitehtuuri , jotta verkkotunnusmallin ongelmat voidaan erottaa infrastruktuurin yksityiskohdista, jotka saavat sovelluksen tosiasiallisesti toimimaan, kuten tietokannat, verkkopalvelimet, välimuistit jne.
  • Model-View Controller on luultavasti tunnetuin arkkitehtuurimalli käyttöliittymäpohjaisten sovellusten kehittämisessä. Se toimii jakamalla sovellus 3 osaan: malli, näkymä ja ohjain. MVC on uskomattoman hyödyllinen, kun aloitat aloituksen, ja se auttaa sinua selittämään muita arkkitehtuureja, mutta on kohta, kun ymmärrämme, että MVC ei riitä ongelmiin, joissa on paljon liiketoimintalogiikkaa.
  • Tapahtumahankinta on toimiva lähestymistapa, jossa tallennamme vain tapahtumat, emmekä koskaan valtiota. Jos tarvitsemme koskaan valtiota, voimme soveltaa kaikkia tapahtumia aikojen alusta.

Vaihe 9: Yrityskuviot

Kaikki valitsemasi arkkitehtoniset mallit esittävät useita rakenteita ja teknistä ammattikieltä perehtymään ja päättämään, onko sen arvoinen käyttää.

Ottaen esimerkin, jonka monet meistä tietävät, MVC : ssä näkymä sisältää kaiken esityskerroksen koodin, ohjain kääntää näkymän komennot ja kyselyt pyyntöiksi, joita malli käsittelee ja ohjain palauttaa .

Missä mallissa (M) käsittelemme näitä asioita ?:

  • validointilogiikka
  • muuttumattomat säännöt
  • verkkotunnuksen tapahtumia
  • Käytä koteloita
  • monimutkaiset kyselyt
  • ja liiketoimintalogiikka

Jos käytämme mallina yksinkertaisesti ORM: ää (objektisuhdekartoitin), kuten Sequelize tai TypeORM , kaikki tärkeät asiat jätetään tulkintaan siitä, mihin sen pitäisi mennä, ja se löytää itsensä jostakin määrittelemättömästä kerroksesta (mikä pitäisi olla rikas ) malli ja ohjain .

mvc-2

Otettu solidbook.io: n "3.1 - Slim (Logic-less) -malleista".

Jos matkallani on jotain, mitä olen oppinut tähän mennessä, ylittää MVC: n, se on, että kaikelle on olemassa rakenne .

Jokaiselle näistä asioista, joita MVC ei pysty ratkaisemaan, on olemassa muita yrityskuvioita niiden ratkaisemiseksi. Esimerkiksi:

  • Entiteetit kuvaavat malleja, joilla on identiteetti.
  • Arvo-objektit ovat malleja, joilla ei ole identiteettiä, ja joita voidaan käyttää validointilogiikan kapseloimiseen.
  • Verkkotunnustapahtumat ovat tapahtumia, jotka merkitsevät joitain asiaankuuluvia yritystapahtumia, ja ne voidaan tilata muista komponenteista.

Valitsemastasi arkkitehtonisesta tyylistä riippuen, sinun on opittava joukko muita yrityskuvioita, jotta voit toteuttaa kyseisen mallin täysimittaisesti.

Integraatiomallit

Kun sovelluksesi on valmis ja käynnissä, kun saat enemmän käyttäjiä, saatat kohdata suorituskykyongelmia. API-puhelut voivat viedä kauan, palvelimet saattavat kaatua ylikuormitusta pyyntöihin jne. Voit ratkaista nämä ongelmat lukemalla esimerkiksi viestijonojen tai välimuistien integroinnin suorituskyvyn parantamiseksi.

Tämä on luultavasti haastavin asia: skaalaus, tarkastukset ja suorituskyky .

Järjestelmän suunnittelu mittakaavassa voi olla uskomattoman haastavaa. Se vaatii syvällistä ymmärrystä kunkin arkkitehtuurin komponentin rajoituksista ja toimintasuunnitelman siitä, miten voit vähentää arkkitehtuurisi stressiä ja jatkaa pyyntöjen palvelua vilkkaassa liikenteessä.

Tarve myös tarkastaa, mitä sovelluksessasi tapahtuu. Suuryritysten on kyettävä suorittamaan auditointeja tunnistaakseen mahdolliset tietoturvaongelmat, ymmärtääkseen kuinka käyttäjät käyttävät sovelluksiaan ja että heillä on loki kaikesta mitä on koskaan tapahtunut.

Tämä voi olla haastavaa toteuttaa, mutta yleiset arkkitehtuurit näyttävät lopulta tapahtumapohjaisilta ja rakentuvat monenlaisiin ohjelmisto- ja järjestelmäsuunnittelukonsepteihin, periaatteisiin ja käytäntöihin, kuten Tapahtumamyrsky, DDD, CQRS (komentokyselyvastausten erottelu) ja Tapahtumahankinta .

Toivon, että siitä oli sinulle hyötyä!

Kerro minulle, jos sinulla on ehdotuksia tai kysymyksiä.

Kippis!

Haarusta se GitHubiin

Lue kirja ohjelmistosuunnittelusta ja arkkitehtuurista

Lue kirjoitus

khalilstemmler.com - Opetan Advanced TypeScript & Node.js: n parhaita käytäntöjä suurille sovelluksille ja kuinka kirjoittaa joustavia, ylläpidettäviä ohjelmistoja.