Kuidas õppida tarkvaradisaini ja arhitektuuri - teekaart

See artikkel on kokkuvõte sellest, millest kirjutan oma uusimas projektis solidbook.io - Tarkvara disaini ja arhitektuuri käsiraamat TypeScriptiga. Vaadake seda, mis teile meeldib see postitus.

Minu jaoks on pöörane arvestada tõsiasjaga, et Facebook oli kunagi kellegi arvutis tühi tekstifail.

Lol.

Eelmisel aastal olen tegelenud kõvasti tarkvara kujundamise ja arhitektuuri, domeenipõhise disaini ja selle kohta raamatu kirjutamisega ning tahtsin võtta hetke, et proovida see kokku panna millekski kasulikuks, mida saaksin kogukonnaga jagada. .

Siin on minu tegevuskava tarkvara kujunduse ja arhitektuuri õppimiseks.

Olen selle jaotanud kaheks esemeks: virn ja kaart .

Virn

Sarnaselt võrguühenduse OSI mudelile ehitab iga kiht eelmise aluse peale.

Virn

Kaart

Kuigi minu arvates on virn hea näha laiemat pilti sellest, kuidas kõik koos töötab, on kaart veidi üksikasjalikum (ja inspireeritud veebiarendaja tegevuskavast) ja seetõttu on see minu arvates kasulikum.

Siin see on allpool! Repo hargnemiseks lugege minu üksikasjalikku kirjutist ja laadige see suure eraldusvõimega alla, klõpsake siin.

Tarkvara kujundamise ja arhitektuuri tegevuskava

1. etapp: puhastage kood

Esimene samm kauakestva tarkvara loomise suunas on nuputada, kuidas puhta koodi kirjutada .

Puhas kood on kood, mida on lihtne mõista ja muuta. Madalal tasemel avaldub see mõne kujundusvalikuna, näiteks:

  • olles järjekindel
  • tähenduslike muutujate, meetodite ja klasside nimede eelistamine kommentaaride kirjutamisele
  • tagades, et kood on taandatud ja paigutatud õigesti
  • kõigi testide läbiviimise tagamine
  • puhaste funktsioonide kirjutamine ilma kõrvalmõjudeta
  • ei möödu null

Puhta koodi kirjutamine on uskumatult oluline.

Mõelge sellele nagu jengamängule.

Selleks, et hoida meie projekti struktuur aja jooksul stabiilsena, tasuvad sellised asjad nagu taandamine, väikesed klassid ja meetodid ning sisukad nimed pikas perspektiivis palju ära.

Parim ressurss puhta koodi kirjutamise õppimiseks onu Bobi raamat "Puhas kood".

2. etapp: programmeerimisparadigmad

Nüüd, kui kirjutame loetava koodi, mida on lihtne hooldada, oleks mõistlik tõepoolest mõista kolme peamist programmeerimisparadigmat ja nende mõju viisile, kuidas me koodi kirjutame.

Onu Bobi raamatus "Puhas arhitektuur" juhib ta tähelepanu asjaolule, et:

  • Objektorienteeritud programmeerimine on tööriist, mis sobib kõige paremini polümorfismi ja pistikprogrammidega arhitektuuripiiride ületamiseks
  • Funktsionaalne programmeerimine on tööriist, mida kasutame andmete viimiseks rakenduste piiridesse
  • ja struktureeritud programmeerimine on tööriist, mida kasutame algoritmide kirjutamiseks

See tähendab, et efektiivne tarkvara kasutab kõigi kolme programmeerimisparadigma hübriidi erinevatel aegadel.

Ehkki koodi kirjutamisel võiksite järgida rangelt funktsionaalset või rangelt objektile suunatud lähenemisviisi, parandab teie kujunduse kvaliteeti mõistmine, kus kumbki silma paistab.

Kui teil on ainult haamer, tundub kõik nagu nael.

Ressursid

Sest funktsionaalne programmeerimine , vaadake:

  • Professor Frisby enamasti adekvaatne juhend funktsionaalse programmeerimise kohta
  • Domeenide modelleerimine toimis

3. etapp: Objektorienteeritud programmeerimine

Oluline on teada, kuidas kõik paradigmad toimivad ja kuidas nad kutsuvad teid üles nende sees olevat koodi üles ehitama, kuid arhitektuuri osas on objektil põhinev programmeerimine selle töö selge tööriist .

Objektorienteeritud programmeerimine võimaldab meil mitte ainult luua pistikprogrammi arhitektuuri ja ehitada oma projektidesse paindlikkust; OOP-l on kaasas 4 OOP-põhimõtet (kapseldamine, pärimine, polümorfism ja abstraktsioon), mis aitavad meil luua rikkaliku domeeni mudeleid .

Enamik objektipõhist programmeerimist õppivatest arendajatest ei jõua kunagi sellesse ossa: õpivad, kuidas luua probleemse domeeni tarkvararakendust, ja leia see kihilise veebirakenduse keskelt .

Funktsionaalne programmeerimine võib tunduda selle stsenaariumi kõigi vahenditena, kuid ma soovitaksin tutvuda mudelipõhise disaini ja domeenipõhise kujundusega, et mõista laiemat pilti sellest, kuidas objektimodelleerijad suudavad kogu ettevõtte kapseldada nullsõltuvuse domeenimudel.

Miks on see tohutu tehing?

See on tohutu, sest kui suudate luua ettevõtte mentaalse mudeli, saate luua selle ettevõtte tarkvara juurutamise.

4. etapp: kujundamise põhimõtted

Siinkohal saate aru, et objektorienteeritud programmeerimine on rikasdomeenimudelite kapseldamiseks ja 3. tüüpi "riistvaraliste probleemide" - keerukate domeenide lahendamiseks väga kasulik.

Kuid OOP võib tuua välja mõned disainiprobleemid.

Millal peaksin kompositsiooni kasutama?

Millal peaksin pärimist kasutama?

Millal peaksin kasutama abstraktset klassi?

Projekteerimispõhimõtted on tõeliselt väljakujunenud ja lahingutes katsetatud objektorienteeritud parimad tavad, mida kasutate raudtee valvuritena.

Mõned näited levinud disainiprintsiipidest, millega peaksite end kurssi viima, on:

  • Koosseis pärimise üle
  • Kapseldage seda, mis varieerub
  • Programm abstraktsioonide, mitte betoonide vastu
  • Hollywoodi põhimõte: "Ärge helistage meile, me helistame teile"
  • SOLID põhimõtted, eriti ühtse vastutuse põhimõte
  • KUIV ​​(Ära korda ennast)
  • YAGNI (te ei vaja seda)

Veenduge, et tulla oma enda järeldused, kuigi. Ärge järgige lihtsalt seda, mida keegi teine ​​peaks tegema. Veenduge, et see oleks teie jaoks mõistlik.

5. etapp: kujundusmustrid

Peaaegu kõik tarkvara probleemid on juba kategoriseeritud ja lahendatud. Me nimetame neid mustreid: tegelikult kujundusmustreid.

Kujundusmustreid on 3 kategooriat: loominguline , struktuurne ja käitumuslik .

Loominguline

Loomemustrid on mustrid, mis kontrollivad objektide loomist.

Loomemustrite näited on järgmised:

  • Singleton muster , tagada ainult ühe eksemplariga klassi saab eksisteerida
  • Abstract Factory muster , loomiseks näiteks mitmest perest klasside
  • Prototüüp struktuuris , alustades läbi üksikjuhuga et oleks kloonitud olemasolevat

Struktuurne

Struktuurimustrid on mustrid, mis lihtsustavad komponentide vaheliste suhete määratlemist.

Konstruktsioonide kujundusmudelite näited on järgmised:

  • Adapter muster , luua liides võimaldab klassid, mis tavaliselt ei saa koos töötada, töötada koos.
  • Bridge muster , purustavat klassi, mis peaks tegelikult olema üks või mitu, hulgaks klassid, mis kuuluvad hierarhia, mis võimaldab rakenduste väljatöötamist üksteisest sõltumatult.
  • Maalritööd muster , lisades kohustusi objektid dünaamiliselt.

Käitumine

Käitumismustrid on esemete vahel elegantse suhtlemise hõlbustamiseks tavalised mustrid.

Näited käitumismustritest on:

  • Mall muster , edasilükkamise täpse etappe algoritmi alamklass.
  • Vahendaja muster , täpse suuruse kindlaksmääramisel sidekanalite lubatud klasside vahel.
  • Observer muster , mis võimaldab klasside tellida midagi huvipakkuvat ja teada saada, millal muutus toimus.

Disainimustri kriitika

Kujundusmustrid on suurepärased ja kõik, kuid mõnikord võivad need meie kujundusele veelgi keerukamaks muutuda. Oluline on meeles pidada YAGNI-d ja püüda hoida meie kujundus võimalikult lihtsana. Kasutage kujundusmustreid ainult siis, kui olete neid kindlasti kindel. Saate teada, millal soovite.

Kui teame, mis on need mustrid, millal neid kasutada ja millal nende kasutamisega isegi mitte vaeva näha , oleme heas vormis, et hakata aru saama, kuidas suuremaid süsteeme üles ehitada.

Selle põhjuseks on asjaolu, et arhitektuurimustrid on lihtsalt kõrgel tasemel puhutud kujundusmustrid , kus kujundusmustrid on madalad rakendused (lähemal klassidele ja funktsioonidele).

Ressursid

Guru ümbertegemine - kujundusmustrid

6. etapp: arhitektuurilised põhimõtted

Nüüd oleme kõrgemal mõtlemistasandil väljaspool klassi taset.

Mõistame nüüd, et otsused, mida langetame komponentide vahel kõrgel ja madalal tasemel suhete loomise ja loomise suunas, mõjutavad oluliselt meie projekti hooldatavust, paindlikkust ja testitavust.

Õppige juhtpõhimõtteid, mis aitavad teil paindlikkust üles ehitada, mida teie koodibaas vajab, et saaksite reageerida uutele funktsioonidele ja nõuetele võimalikult vähese vaevaga.

Siin on see, mida ma soovitaksin kohe õppida:

  • Komponentide kujundamise põhimõtted: stabiilse abstraktsiooni põhimõte, stabiilse sõltuvuse põhimõte ja atsüklilise sõltuvuse põhimõte komponentide korrastamiseks, nende sõltuvuste kohta, millal neid paaritada, ning tagajärjed juhusliku sõltuvustsüklite loomise ja ebastabiilsetele komponentidele toetumise kohta.
  • Reeglid vs detail, et mõista, kuidas rakenduse reeglid rakenduse üksikasjadest eraldada
  • Piirid ja kuidas tuvastada alamdomeene, kuhu teie rakenduse funktsioonid kuuluvad.

Onu Bob avastas ja algselt dokumenteeris paljud neist põhimõtetest, nii et parim ressurss selle kohta on taas "Puhas arhitektuur".

7. etapp: arhitektuurilised stiilid

Arhitektuur on seotud olulise kraamiga.

See seisneb selles, et teha kindlaks, mida süsteem vajab edukaks saamiseks, ja seejärel laduda edukuse tõenäosus, valides nõuetele kõige paremini sobiva arhitektuuri.

Näiteks oleks süsteemil, millel on palju äriloogika keerukust, kasuks kihilise arhitektuuri kasutamine selle keerukuse kapseldamiseks.

Süsteem nagu Uber peab suutma korraga käsitseda paljusid reaalajas toimuvaid sündmusi ja värskendada draiverite asukohti, nii et avaldamise-tellimise stiilis arhitektuur võib olla kõige tõhusam.

Kordan ennast siin, sest on oluline märkida, et arhitektuuristiilide 3 kategooriat sarnanevad 3 kujundusmustrite kategooriaga, sest arhitektuuristiilid on kõrgel tasemel kujundusmustrid .

Struktuurne

Projektid erineva komponentide ja laiaulatuslik funktsionaalsus kas kasu või kannatavad vastu struktuurne ülesehitus.

Siin on mõned näited:

  • Komponendipõhised arhitektuurid rõhutavad murede eraldamist süsteemi üksikute komponentide vahel. Mõelge mõni sekund Google'ile . Mõelge, kui palju rakendusi neil ettevõttes on (Google Docs, Google Drive, Google Maps jne). Paljude funktsionaalsustega platvormide puhul jagavad komponendipõhised arhitektuurid probleemid vabalt ühendatud iseseisvateks komponentideks. See on horisontaalne eraldamine.
  • Monoliitne tähendab, et rakendus on ühendatud üheks platvormiks või programmiks, mis on täielikult juurutatud. Märkus. Kui eraldate oma rakendused korralikult, kuid juurutate kõik ühe osana, võib teil olla komponendipõhine JA monoliitne arhitektuur .
  • Kihilised arhitektuurid eraldavad probleemid vertikaalselt , lõigates tarkvara infrastruktuuri-, rakendus- ja domeenikihtidesse.

Puhas arhitektuur

Näide rakenduse probleemide vertikaalseks lõikamiseks kihilise arhitektuuri abil. Lisateavet selle kohta saate siit.

Sõnumid

Sõltuvalt teie projektist võib sõnumside olla süsteemi edukuse oluline komponent. Selliste projektide puhul põhinevad sõnumipõhised arhitektuurid funktsionaalsete programmeerimispõhimõtete ja käitumuslike kujundusmudelite, näiteks vaatleja mustri peal.

Siin on mõned näited sõnumipõhistest arhitektuuristiilidest:

  • Sündmuspõhised arhitektuurid käsitlevad kõiki märgilisi oleku muudatusi sündmustena. Näiteks võib vinüüliga kauplemise rakenduses muutuda pakkumise olek "ootel" olekust "aktsepteeritud", kui mõlemad pooled on kaubanduses kokku leppinud.
  • Avaldamise-tellimise arhitektuurid põhinevad Observeri kujundusmudelil, muutes selle peamiseks suhtlusmeetodiks süsteemi enda, lõppkasutajate / klientide ning teiste süsteemide ja komponentide vahel.

Levitatakse

Hajutatud arhitektuur tähendab lihtsalt seda, et süsteemi komponendid on paigutatud eraldi ja töötavad võrguprotokolli kaudu suheldes. Hajutatud süsteemid võivad olla väga tõhusad läbilaskevõime skaleerimiseks, meeskondade skaleerimiseks ja (potentsiaalselt kallite ülesannete või vastutuse) delegeerimiseks teistele komponentidele.

Mõned näited hajutatud arhitektuuristiilidest on:

  • Kliendi-serveri arhitektuur. Üks levinumaid arhitektuure, kus jagame tehtavad tööd kliendi (esitlus) ja serveri (äriloogika) vahel.
  • Peer-to-peer- arhitektuurid jagavad rakenduskihi ülesandeid võrdselt privilegeeritud osalejate vahel, moodustades peer-to-peer võrgu.

8. etapp: arhitektuurimustrid

Arhitektuuri mustrid selgitan taktikalised üksikasjalikult, kuidas tegelikult rakendada üks neist arhitektuuri stiile .

Siin on paar näidet arhitektuurimustritest ja stiilidest, millest nad pärivad:

  • Domeenipõhine disain on lähenemine tarkvaraarendusele tõeliselt keeruliste probleemdomeenide vastu. Selleks, et DDD oleks kõige edukam, peame rakendama kihilise arhitektuuri , et eraldada domeenimudeli probleemid infrastruktuuri üksikasjadest, mis panevad rakenduse tegelikult käima, näiteks andmebaasid, veebiserverid, vahemälud jne.
  • Model-View Controller on ilmselt kõige tuntum arhitektuuriline muster kasutajaliidepõhiste rakenduste arendamiseks. See töötab, jagades rakenduse kolmeks komponendiks: mudel, vaade ja kontroller. MVC on uskumatult kasulik, kui te esimest korda alustate, ja see aitab teil teiste arhitektuuride poole jõuda, kuid on tabanud punkt, kui mõistame, et MVC-st ei piisa paljude äriloogikaga seotud probleemide jaoks.
  • Sündmuste hankimine on funktsionaalne lähenemisviis, kus me salvestame ainult tehingud ja mitte kunagi riiki. Kui meil on kunagi riiki vaja, saame kõiki tehinguid rakendada aegade algusest.

9. etapp: ettevõtte mustrid

Kõik valitud arhitektuurimustrid tutvustavad paljusid konstruktsioone ja tehnilist žargooni, et end kurssi viia ja otsustada, kas tasub vaeva näha või mitte.

Kui võtta näide, et paljud meist teavad, siis MVC-s on vaates kogu esitluskihi kood, kontroller tõlgib vaatest käsud ja päringud päringuteks, mida mudel käsitseb ja kontroller tagastab .

Kus mudelis (M) me neid asju käsitleme ?:

  • valideerimise loogika
  • muutumatud reeglid
  • domeeni sündmused
  • kasutamise juhtumid
  • keerulised päringud
  • ja äriloogika

Kui me lihtsalt kasutada ORM (object-relational kaardistaja) nagu Sequelize või TypeORM nagu mudel , kõik, mis oluline kraami saab jätta tõlgendamise kohta, kus see peaks minema, ja ta leiab ise mõned määratlemata kihi vahel (mis peaks olema rikas ) mudel ja kontroller .

mvc-2

Võetud saidilt solidbook.io "3.1 - õhukesed (ilma loogikata) mudelid".

Kui minu teekonnal on midagi, mida olen MVC-st kaugemale õppinud, on see, et kõige jaoks on olemas konstruktsioon .

Kõigi nende asjade puhul, mida MVC ei lahenda, on nende lahendamiseks olemas muud ettevõtte mustrid . Näiteks:

  • Üksused kirjeldavad mudeleid, millel on identiteet.
  • Väärtusobjektid on mudelid, millel puudub identiteet ja mida saab kasutada valideerimisloogika kapseldamiseks.
  • Domeenisündmused on sündmused, mis tähistavad mõne asjakohase äriürituse toimumist ja mida saab tellida muudest komponentidest.

Sõltuvalt teie valitud arhitektuuristiilist on teie õppimiseks veel palju muid ettevõtte mustreid, et seda mustrit maksimaalselt rakendada.

Integratsioonimustrid

Kui teie rakendus on töökorras ja üha enam kasutajaid juurde saate, võib teil tekkida jõudlusprobleeme. API-kõned võivad võtta kaua aega, serverid võivad kokku kukkuda päringutest ülekoormuse jms tõttu. Nende probleemide lahendamiseks võite jõudluse parandamiseks lugeda selliste asjade integreerimist nagu sõnumijärjekorrad või vahemälud .

See on ilmselt kõige keerulisem värk: skaleerimine, auditid ja jõudlus .

Mastaabisüsteemi kujundamine võib olla uskumatult keeruline. See nõuab arhitektuuri iga komponendi piirangute põhjalikku mõistmist ja tegevuskava selle kohta, kuidas vähendada oma arhitektuuri stressi ja jätkata taotluste esitamist tiheda liiklusega olukordades.

Vajadus kontrollida ka teie rakenduses toimuvat. Suured ettevõteettevõtted peavad suutma teha auditeid, et tuvastada potentsiaalsed turvaküsimused, mõista, kuidas kasutajad oma rakendusi kasutavad, ja neil on logi kõigest, mis kunagi juhtunud on.

Seda saab väljakutse rakendada, kuid ühise arhitektuuri lõpuks otsin juhul põhinev ja tuginema laia tarkvara ja süsteemi projekteerimise mõisted, põhimõtted ja tavad, nagu Event Storming, DDD, CQRS (käsk päringule vastuseks eraldamine), ja Event allhange .

Loodan, et see oli teile kasulik!

Andke mulle teada, kui teil on ettepanekuid või küsimusi.

Terviseks!

Kahvli see GitHubis

Lugege raamatut tarkvara kujunduse ja arhitektuuri kohta

Lugege kirjutist üles

khalilstemmler.com - õpetan Advanced TypeScript & Node.js parimaid tavasid suuremahuliste rakenduste jaoks ning paindliku ja hooldatava tarkvara kirjutamist.