Kaip išmokti programinės įrangos projektavimą ir architektūrą - gairės

Šis straipsnis yra santrauka to, apie ką rašau savo naujausiame projekte „solidbook.io“ - Programinės įrangos projektavimo ir architektūros su „TypeScript“ vadovas. Patikrinkite, ar jums patinka šis pranešimas.

Man beprotiška atsižvelgti į tai, kad „Facebook“ kažkieno kompiuteryje kažkada buvo tuščias tekstinis failas.

Daug juoko.

Praėjusiais metais aš sunkiai ėmiausi programinės įrangos projektavimo ir architektūros, domenų valdomo dizaino ir rašiau apie tai knygą, ir norėjau skirti šiek tiek laiko pabandyti ją sujungti į kažką naudingo, kuo galėčiau pasidalinti su bendruomene. .

Čia yra mano planas, kaip išmokti programinės įrangos projektavimo ir architektūros.

Aš suskaidiau jį į du artefaktus: kaminą ir žemėlapį .

„Stack“

Panašiai kaip OSI tinkle, kiekvienas sluoksnis yra pastatytas ant ankstesnio pagrindo.

Šūsnis

Žemėlapis

Nors manau, kad kaminas yra geras norint pamatyti didesnį vaizdą apie tai, kaip viskas veikia kartu, žemėlapis yra šiek tiek išsamesnis (ir įkvėptas žiniatinklio kūrėjų plano), todėl manau, kad jis yra naudingesnis.

Štai jis yra žemiau! Norėdami išsišakoti atpirkimą, perskaitykite išsamų mano užrašą ir atsisiųskite jį dideliu vaizdu, spustelėkite čia.

Programinės įrangos projektavimo ir architektūros planas

1 etapas: išvalykite kodą

Pirmasis žingsnis kuriant ilgalaikę programinę įrangą yra išsiaiškinti, kaip parašyti švarų kodą .

Švarus kodas yra kodas, kurį lengva suprasti ir pakeisti. Žemu lygiu tai pasireiškia keletu dizaino pasirinkimų, tokių kaip:

  • būdamas nuoseklus
  • pirmenybė teikiama prasmingam kintamajam, metodo ir klasės pavadinimams, o ne komentarų rašymui
  • užtikrinant, kad kodas būtų įdėtas ir išdėstytas tinkamai
  • užtikrinant, kad visi bandymai gali būti vykdomi
  • rašyti grynas funkcijas be šalutinių poveikių
  • nepraeina null

Nepaprastai svarbu parašyti švarų kodą.

Pagalvokite apie tai kaip apie jengos žaidimą.

Norint, kad mūsų projekto struktūra laikui bėgant būtų stabili, tokie dalykai kaip įtrauka, mažos klasės ir metodai bei prasmingi pavadinimai ilgainiui labai atsiperka.

Geriausias šaltinis, norint išmokti rašyti švarų kodą, yra dėdės Bobo knyga „Švarus kodas“.

2 etapas: programavimo paradigmos

Dabar, kai rašome įskaitomą kodą, kurį lengva prižiūrėti, būtų gera idėja iš tikrųjų suprasti 3 pagrindines programavimo paradigmas ir jų įtaką, kaip mes rašome kodą.

Dėdės Bobo knygoje „Švari architektūra“ jis atkreipia dėmesį į tai, kad:

  • Objektinis programavimas yra įrankis, geriausiai tinkantis apibrėžti, kaip mes peržengiame architektūrines ribas su polimorfizmu ir įskiepiais
  • Funkcinis programavimas yra įrankis, kurį naudojame norėdami perkelti duomenis į savo programų ribas
  • Struktūrizuotas programavimas yra įrankis, kurį naudojame algoritmams rašyti

Tai reiškia, kad efektyvi programinė įranga naudoja hibridinius visus 3 programavimo paradigmų stilius skirtingu metu.

Nors rašydami kodą galėtumėte laikytis griežtai funkcinio ar griežtai objektyvaus požiūrio, suprasdami, kur kiekvienas išsiskiria, pagerinsite savo dizaino kokybę.

Jei viskas, ką turite, yra plaktukas, viskas atrodo kaip vinis.

Ištekliai

Norėdami atlikti funkcinį programavimą , patikrinkite:

  • Profesoriaus Frisby dažniausiai adekvatus funkcinio programavimo vadovas
  • Domeno modeliavimas tapo funkcionalus

3 etapas: į objektą orientuotas programavimas

Svarbu žinoti, kaip veikia kiekviena iš paradigmų ir kaip jos ragina jus struktūrizuoti jose esantį kodą, tačiau architektūros požiūriu į objektą orientuotas programavimas yra aiški darbo priemonė .

Objektinis programavimas ne tik leidžia mums sukurti įskiepių architektūrą ir integruoti savo projektus; OOP ateina su 4 OOP principais (inkapsuliacija, paveldėjimas, polimorizmas ir abstrakcija), kurie padeda mums sukurti turtingus domenų modelius .

Dauguma kūrėjų, besimokančių į objektą orientuoto programavimo, niekada nepatenka į šią dalį: mokosi sukurti programinės įrangos problemos domeno diegimą ir jo vietą daugiasluoksnės žiniatinklio programos centre.

Funkcinis programavimas gali atrodyti kaip priemonė visiems šio scenarijaus tikslams pasiekti, tačiau aš rekomenduočiau susipažinti su modeliu pagrįstu dizainu ir domenų valdomu dizainu, kad suprastumėte didesnį vaizdą apie tai, kaip objektų modeliai sugeba apimti visą verslą nulinės priklausomybės domeno modelis.

Kodėl tai yra didžiulis sandoris?

Tai didžiulė, nes jei galite sukurti mentalinį verslo modelį, galite sukurti to verslo programinę įrangą.

4 etapas: projektavimo principai

Šiuo metu suprantate, kad į objektą orientuotas programavimas yra labai naudingas kaupiant turtingo domeno modelius ir sprendžiant 3-iojo tipo „kietosios programinės įrangos problemas“ - sudėtingus domenus.

Tačiau OOP gali sukelti keletą dizaino iššūkių.

Kada turėčiau naudoti kompoziciją?

Kada turėčiau naudoti paveldėjimą?

Kada turėčiau naudoti abstrakčią klasę?

Dizaino principai yra tikrai nusistovėjusi ir mūšyje patikrinta objektų orientuota geriausia praktika, kurią naudojate kaip bėgio apsaugą.

Keletas bendrų projektavimo principų, su kuriais turėtumėte susipažinti, pavyzdžiai:

  • Sudėtis dėl paveldėjimo
  • Apimkite tai, kas skiriasi
  • Programa prieš abstrakcijas, o ne konkretizacijas
  • Holivudo principas: „Neskambinkite mums, mes jums paskambinsime“
  • SOLID principai, ypač bendros atsakomybės principas
  • SAUSA (nekartokite savęs)
  • YAGNI (jums to nereikės)

Vis dėlto įsitikinkite, kad padarėte savo išvadas. Nesilaikykite tik to, ką turite pasakyti kažkas kitas. Įsitikinkite, kad tai prasminga jums.

5 etapas: dizaino modeliai

Beveik kiekviena programinės įrangos problema jau buvo suskirstyta į kategorijas ir išspręsta. Mes vadiname šiuos modelius: iš tikrųjų dizaino modelius.

Yra 3 dizaino modelių kategorijos: kūrybos , struktūros ir elgesio .

Kūrybos

Kūrybiniai modeliai yra modeliai, kurie valdo objektų kūrimą.

Kūrybinių modelių pavyzdžiai:

  • Singleton“ modelis , užtikrinantis tik vieną klasės egzempliorių, gali egzistuoti
  • Abstract Factory“ modelis , skirtas sukurti kelių klasių šeimų egzempliorių
  • Prototipas modelis , už pradedate su instancijos kuris yra klonuotų ne nuo esamo

Struktūrinis

Struktūriniai modeliai yra modeliai, kurie supaprastina santykių tarp komponentų apibrėžimą.

Konstrukcijos projektavimo modelių pavyzdžiai:

  • Adapteris modelis , skirtas sukurti sąsają, kad būtų galima klases, kurios paprastai negali dirbti kartu, dirbti kartu.
  • Bridge“ modelis , skirtas suskirstyti klasę, kuri iš tikrųjų turėtų būti viena ar kelios, į klasių rinkinį, priklausantį hierarchijai, leidžiančią plėtoti kūrinius nepriklausomai vienas nuo kito.
  • Decorator“ modelis , skirtas dinamiškai pridėti objektų.

Elgesys

Elgesio modeliai yra įprasti modeliai, palengvinantys elegantišką bendravimą tarp objektų.

Elgesio modelių pavyzdžiai:

  • Šablonas modelis , skirtas atidėti tikslius veiksmus algoritmą į poklasio.
  • Mediator“ modelis , skirtas apibrėžti tikslius bendravimo kanalus, leidžiamus tarp klasių.
  • Stebėtojas modelis , įgalinant klases prenumeruoti kažką interesų, o turi būti pranešama, kai įvyko pokytis.

Dizaino modelio kritika

Dizaino modeliai yra puikūs ir visi, tačiau kartais jie gali papildyti mūsų dizainą. Svarbu prisiminti „YAGNI“ ir stengtis, kad mūsų dizainas būtų kuo paprastesnis. Dizaino modelius naudokite tik tada, kai tikrai esate tikri. Jūs žinosite kada.

Jei žinome, kas yra kiekvienas iš šių modelių, kada juos naudoti ir kada net nesivarginti juos naudojant, esame geros formos, kad galėtume suprasti, kaip kurti didesnes sistemas.

To priežastis yra ta, kad architektūriniai modeliai yra tik dizaino modeliai, susprogdinti iki aukšto lygio , kur dizaino modeliai yra žemo lygio įgyvendinimai (arčiau klasių ir funkcijų).

Ištekliai

„Guru“ pertvarkymas - dizaino modeliai

6 etapas: architektūros principai

Dabar mes esame aukštesniame mąstymo lygyje už klasės lygio ribų.

Dabar suprantame, kad sprendimai, kuriuos priimame siekdami organizuoti ir kurti santykius tarp komponentų aukšto ir žemo lygio, turės reikšmingą įtaką mūsų projekto išlaikomumui, lankstumui ir testavimui.

Sužinokite pagrindinius principus, kurie padeda jums sukurti lankstumą, kurio reikia jūsų kodų bazei, kad galėtumėte kuo mažiau reaguoti į naujas funkcijas ir reikalavimus.

Štai ką aš rekomenduočiau išmokti iškart:

  • Komponentų projektavimo principai: stabilaus abstrakcijos principas, stabilaus priklausomybės principas ir aciklinio priklausomybės principas, kaip organizuoti komponentus, jų priklausomybes, kada juos suporuoti, taip pat netyčinio priklausomybės ciklų sukūrimo ir pasikliavimo nestabiliais komponentais pasekmės.
  • Politika ir išsami informacija, kad suprastumėte, kaip atskirti programos taisykles nuo išsamios įgyvendinimo.
  • Ribos ir kaip nustatyti padomenius, kuriems priklauso jūsų programos funkcijos.

Dėdė Bobas atrado ir iš pradžių dokumentavo daugelį šių principų, todėl geriausias šaltinis apie tai vėlgi yra „Švari architektūra“.

7 etapas: architektūros stiliai

Architektūra yra svarbūs dalykai.

Tai yra nustatyti, ko reikia sistemai, kad ji būtų sėkminga, ir sukrauti sėkmės tikimybę, pasirinkdami geriausiai reikalavimus atitinkančią architektūrą.

Pavyzdžiui, sistemai, turinčiai daug verslo logikos sudėtingumo, būtų naudinga naudoti daugiasluoksnę architektūrą, kad būtų galima sukomplektuoti šį sudėtingumą.

Tokia sistema kaip „Uber“ turi sugebėti vienu metu valdyti daugybę įvykių realiuoju laiku ir atnaujinti tvarkyklių vietas, todėl „ Publish-Subscribe“ stiliaus architektūra gali būti efektyviausia.

Aš pasikartosiu čia, nes svarbu pažymėti, kad 3 architektūros stilių kategorijos yra panašios į 3 dizaino raštų kategorijas, nes architektūros stiliai yra aukšto lygio dizaino modeliai .

Struktūrinis

Projektai, turintys skirtingo lygio komponentus ir plataus masto funkcionalumą, bus naudingi arba kenks dėl struktūrinės architektūros pritaikymo.

Štai keli pavyzdžiai:

  • Komponentais pagrįstos architektūros pabrėžia atskirų sistemos komponentų rūpesčių atskyrimą . Pagalvokite apie „ Google “. Apsvarstykite, kiek programų jie turi savo įmonėje („Google“ dokumentai, „Google“ diskas, „Google“ žemėlapiai ir kt.). Daug funkcijų turinčioms platformoms komponentų pagrindu sukurtos architektūros rūpesčius padalija į laisvai sujungtus nepriklausomus komponentus. Tai horizontalus atskyrimas.
  • Monolitinis reiškia, kad programa yra sujungta į vieną platformą ar programą, iš viso įdiegtą. Pastaba: Komponentais pagrįstą IR monolitinę architektūrą galite turėti, jei tinkamai atskiriate programas, tačiau visa tai diegiate kaip vieną dalį .
  • Sluoksniuotos architektūros atskiria problemas vertikaliai , suskirstydamos programinę įrangą į infrastruktūros, programų ir domenų sluoksnius.

Švari architektūra

Pavyzdys, kaip vertikaliai sumažinti programos problemas naudojant sluoksniuotą architektūrą. Skaitykite čia, jei norite gauti daugiau informacijos, kaip tai padaryti.

Pranešimai

Priklausomai nuo jūsų projekto, pranešimai gali būti tikrai svarbus sistemos sėkmės komponentas. Tokių projektų atveju pranešimais pagrįstos architektūros remiasi funkciniais programavimo principais ir elgesio dizaino modeliais, tokiais kaip stebėtojų modelis.

Štai keletas pranešimais paremtų architektūrinių stilių pavyzdžių:

  • Įvykių varomos architektūros visus reikšmingus būsenos pakeitimus laiko įvykiais. Pavyzdžiui, vinilo prekybos programoje pasiūlymo būsena gali pasikeisti iš „laukia“ į „priimta“, kai abi šalys susitaria dėl prekybos.
  • Paskelbimo-prenumeratos architektūros remiasi „Observer“ dizaino modeliu, paverčiant ją pagrindiniu komunikacijos metodu tarp pačios sistemos, galutinių vartotojų / klientų ir kitų sistemų bei komponentų.

Paskirstyta

Paskirstyta architektūra paprasčiausiai reiškia, kad sistemos komponentai yra išdėstyti atskirai ir veikia bendraujant tinklo protokolu. Paskirstytos sistemos gali būti labai veiksmingos pralaidumui didinti, komandoms keisti ir (galbūt brangių užduočių ar) atsakomybės perdavimui kitiems komponentams.

Keli paskirstytų architektūros stilių pavyzdžiai:

  • Kliento-serverio architektūra. Viena iš labiausiai paplitusių architektūrų, kai atliekamą darbą mes padalijame tarp kliento (pristatymas) ir serverio (verslo logika).
  • Peer-to-peer architektūros paskirsto programų lygmens užduotis tarp vienodai privilegijuotų dalyvių, formuodamos peer-to-peer tinklą.

8 etapas: architektūriniai modeliai

Architektūriniai modeliai taktiškiau paaiškina, kaip iš tikrųjų įgyvendinti vieną iš šių architektūros stilių .

Štai keletas architektūrinių modelių ir stilių, iš kurių jie paveldi, pavyzdžių:

  • Domenu pagrįstas dizainas yra požiūris į programinės įrangos kūrimą, atsižvelgiant į tikrai sudėtingas problemines sritis. Kad DDD būtų sėkmingiausia, turime įdiegti daugiasluoksnę architektūrą , kad galėtume atskirti domeno modelio problemas nuo infrastruktūros detalių, dėl kurių programa iš tikrųjų veikia, pvz., Duomenų bazės, žiniatinklio serveriai, talpyklos ir kt.
  • „Model-View“ valdiklis yra bene geriausiai žinomas architektūrinis modelis, kuriantis vartotojo sąsaja pagrįstas programas. Tai veikia padalijant programą į 3 komponentus: modelį, vaizdą ir valdiklį. MVC yra nepaprastai naudingas, kai tik pradedate, ir tai padeda jums prisitaikyti prie kitų architektūrų, tačiau yra taškas, kai suprantame, kad MVC nepakanka problemoms, susijusioms su daugeliu verslo logikų.
  • Įvykių šaltinis yra funkcinis metodas, kai mes saugome tik operacijas, o ne valstiją. Jei mums kada nors reikalinga valstybė, visas operacijas galime taikyti nuo laiko pradžios.

9 etapas: Įmonių modeliai

Bet koks pasirinktas architektūrinis raštas supažindins su daugybe konstrukcijų ir techniniu žargonu, kad galėtų susipažinti ir nuspręsti, ar verta stengtis naudoti, ar ne.

Atsižvelgiant pavyzdį, kad daugelis iš mūsų žino, kad MVC , The View turi visą pateikimo sluoksniu kodą, The valdiklis yra verčia komandas ir klausimus iš atsižvelgiant į prašymų, kurie yra tvarkomi pagal modelį ir grįžo į valdiklio .

Kur modelyje (M) mes tvarkome šiuos dalykus ?:

  • patvirtinimo logika
  • nekintančios taisyklės
  • domeno įvykiai
  • naudojimo atvejai
  • sudėtingos užklausos
  • ir verslo logika

Jei paprasčiausiai kaip modelį naudojame ORM (objektų-reliacijų žemėlapį), pvz., „Sequelize“ arba „TypeORM“ , visa tai, kas svarbiausia, paliekama interpretuoti, kur jis turėtų eiti, ir jis atsiduria kažkokiame nenurodytame sluoksnyje tarp (kas turėtų būti turtingas) ) modelį ir valdiklį .

mvc-2

Paimta iš „3.1 - Slim (Logic-less) modelių“, esančių solidbook.io.

Jei mano kelionėje yra kažkas, ko išmokau iki šiol, peržengia MVC ribas, tai yra viskas, kas sukurta .

Kiekvienam iš tų dalykų, kurių MVC nesugeba išspręsti, egzistuoja kiti įmonės modeliai, kaip juos išspręsti. Pavyzdžiui:

  • Subjektai apibūdina modelius, kurie turi tapatybę.
  • „Vertės objektai“ yra modeliai, neturintys tapatybės ir gali būti naudojami patvirtinimo logikai apibendrinti.
  • Domeno įvykiai yra įvykiai, žymintys įvykusius svarbius verslo įvykius, kuriuos galima užsisakyti iš kitų komponentų.

Atsižvelgiant į pasirinktą architektūros stilių, jums teks išmokti daugybę kitų įmonės modelių, kad galėtumėte kuo geriau įgyvendinti šį modelį.

Integracijos modeliai

Kai jūsų programa bus paleista ir paleista, sulaukus vis daugiau vartotojų, gali kilti našumo problemų. API skambučiai gali užtrukti ilgai, serveriai gali užstrigti perkraunant užklausomis ir pan. Norėdami išspręsti šias problemas, galite perskaityti apie tokių dalykų kaip žinučių eilių ar talpyklų integravimą , kad pagerintumėte našumą.

Tai tikriausiai yra pats sudėtingiausias dalykas: mastelio keitimas, auditai ir našumas .

Suprojektuoti masto sistemą gali būti nepaprastai sudėtinga. Tam reikia giliai suprasti kiekvieno komponento apribojimus architektūroje ir veiksmų planą, kaip sušvelninti stresą savo architektūrai ir toliau teikti užklausas didelio eismo situacijose.

Taip pat reikia patikrinti, kas vyksta jūsų programoje. Didelės įmonės turi sugebėti atlikti auditą, kad galėtų nustatyti galimas saugumo problemas, suprasti, kaip vartotojai naudoja savo programas, ir turėti visko, kas kada nors įvyko, žurnalą.

Tai gali būti nelengva įgyvendinti, tačiau bendros architektūros galų gale atrodo pagal įvykius ir remiasi įvairiomis programinės įrangos ir sistemos projektavimo koncepcijomis, principais ir praktika, pvz., „Įvykių audra“, „DDD“, „CQRS“ (komandos užklausos atsako atskyrimas) ir įvykių šaltinis .

Tikiuosi, kad tai buvo naudinga jums!

Praneškite man, jei turite kokių nors pasiūlymų ar klausimų.

Cheers!

Šakė jį „GitHub“

Perskaitykite knygą apie programinės įrangos dizainą ir architektūrą

Perskaitykite užrašą

khalilstemmler.com - Aš mokau „Advanced TypeScript & Node.js“ gerosios patirties, susijusios su didelio masto programomis, ir kaip rašyti lanksčią, prižiūrimą programinę įrangą.