Rahul Mhatre yra „Built.io“ techninis architektas.
„Node.js“ greitai pasiekia „Java“, „Ruby“, „Python“ ir .Net kaip pageidaujamą kalbą kuriant naujas žiniatinklio programas. „Node.js“ komanda kiekvieną dieną daro „JavaScript“ vykdymo laiką geresnį, greitesnį ir tvirtesnį. Vartotojų bendruomenė auga sparčiu klipu.
Kai įsisavinimas vis didėja, vis daugiau kūrėjų perkops „Node.js“ mokymosi kreivę, susidurdami su panašiomis problemomis ir koduodami panašias funkcijas. Laimei, „Node.js“ bendruomenė į pagalbą pasitelkė sistemas ir dizaino modelius, kurie ne tik išsprendžia įprastas problemas, bet ir padeda struktūrizuoti programas.
Karkasai paprastai įgyvendina MV modelius, tokius kaip MVC (model-view-controller), MVVM (model-view-viewmodel), MVP (model-view-presenter) arba tiesiog MV. Jie taip pat nurodo, kur turėtų būti modelių, rodinių ir valdiklių kodas, kur turėtų būti jūsų maršrutai ir kur turėtumėte pridėti savo konfigūracijas. Daugelis jaunų kūrėjų ir „Node.js“ entuziastų nelabai supranta, kaip dizaino modeliai arba OOP (Object Oriented Programming) diagramos susiejamos su jų programoje esančiomis kodais.
Štai kur atsiranda „Node.js“ sistemos, pvz., „Express.js“ ir „Sails.js“. Šios ir daugelis kitų yra prieinamos padėti pradėti kurti žiniatinklio programas. Nepriklausomai nuo to, kokią sistemą naudojate, struktūrizuodami programą, turėtumėte nepamiršti tam tikrų aspektų.
Štai septyni pagrindiniai dalykai, kuriuos apmąstau prieš atvaizduodamas „Node.js“ programą.
1. Tinkama programos katalogo struktūra
Sprendžiant dėl programos katalogo struktūros, turėtumėte atsižvelgti į pasirinktą dizaino modelį. Tai padės greičiau prisijungti, rasti kodą ir greičiau izoliuoti problemas. Aš asmeniškai norėčiau naudoti MVC modelį kurdamas „Node.js“ programą. Tai padeda man vystytis greičiau, suteikia lankstumo kuriant kelis rodinius tiems patiems duomenims ir leidžia asinchroniškai bendrauti ir izoliuoti MVC komponentus.
Man patinka sekti aukščiau parodytą katalogų struktūrą, kuri paremta „Ruby on Rails“ ir „Express.js“ deriniu.
Susijęs vaizdo įrašas: „Node.js“ patarimai ir gudrybės
Šiame aiškinamojo vaizdo įraše sužinokite keletą būdų, kurie gali pagerinti jūsų mazgų kūrimo patirtį.
2. ER diagramų susiejimas su modeliais
Kaip apibrėžta „Techopedia“, „Subjektų ir santykių diagrama (ERD) yra duomenų modeliavimo technika, grafiškai iliustruojanti informacinės sistemos objektus ir santykius tarp tų subjektų“. ER diagrama apibūdina įvairius subjektus, kurie dalyvaus mūsų sistemoje, ir apibrėžia visas jų sąveikas taip:
- Viskas, kas yra abstraktus ar fizinis „daiktas“, tampa modelio esybe
- Modelis susiejamas su lentele mūsų duomenų bazėje
- Esybės atributas arba ypatybė verčiami į modelio atributą, kuris savo ruožtu yra stulpelis lentelės viduje
Pvz., Jei jūsų subjektas yra vartotojas, atitinkamas modelis būtų „Vartotojas“ su tokiais atributais kaip vardas_pavadinimas, pavardė ir adresas duomenų bazėje, taip pat su atitinkama lentele ir stulpeliais.
Naudojant paprastą duomenų architektūrą, gana paprasta sekti savo duomenų bazės ir failų augimą bet kada, kai sukuriama nauja schema.
3. Naudojant MVP modelį
MVC diegimas nereiškia, kad reikia sukurti tik aplankus valdikliams, rodiniams ir modeliams. Taip pat turite padalyti savo kodą ir logiką pagal MVC. Jūsų modelių kodas turėtų būti griežtai ribojamas duomenų bazių schemų apibrėžimais. Kūrėjai paprastai pamiršta, kad modeliai taip pat turės kodą, kuris atliks CRUD operacijas. Be to, šiame faile turėtų būti visos funkcijos ar operacijos, būdingos tam modeliui. Dauguma su logika susijusios verslo logikos turėtų būti šiame faile.
Dažna klaida yra visos verslo logikos išmetimas į valdiklius. Valdikliai turėtų remtis tik modelių ar kitų komponentų funkcijomis, perduoti duomenis tarp komponentų ir valdyti užklausos srautą, o rodinio aplanke turėtų būti tik kodas, kad objektai būtų konvertuojami į žmonėms suprantamą formą. Rodinyje neturėtų būti atliekama jokia logika, kaip duomenų formatavimas, rūšiavimas ar filtravimas. Jei vaizdai bus švarūs, bus suteikta ne tik geresnė vartotojo patirtis, bet ir padedama pakeisti vaizdus nekeičiant jokių kitų komponentų.
4. Logikos išskirstymas į modulius
Kaip kūrėjams, mums visada sakoma, kad turėtume organizuoti kodą į failus ir modulius. Tai nereiškia, kad turėtume bandyti sutalpinti visą programą į vieną failą. Geriausias būdas yra padalinti kodą pagal logiką ir funkcionalumą. Su vienu objektu ar objektu susijusių funkcijų grupavimas į vieną failą ir katalogų struktūros organizavimas remiantis logika turi daug privalumų. Pirma, tai sutaupys daug laiko nustatant, kurią funkciją paliesti, kai reikia ištaisyti klaidą. Antra, tai padeda atsieti visus architektūros komponentus, palengvina atskirų funkcijų pakeitimą nereikalaujant keisti kitų kodo eilučių. Trečia, tai taip pat padės rašyti bandomąsias bylas.
5. Testinių atvejų svarba
Statant bandymų atvejus labai svarbu niekada nenukirsti kampų - testai yra jūsų kodo bazės globėjai. Augant jūsų programai tampa sunkiau prisiminti visus scenarijus, kuriuos turite aprėpti, kai koduojate. Testiniai atvejai padeda išlaikyti stabilų kodų bazę. Testavimas apsaugo nuo regresijos, taupo brangų kūrimo laiką ir pastangas. Tai padeda užtikrinti, kad naujos funkcijos bus įdiegtos be klaidų. Tai taip pat padeda pagerinti kodo kokybę gaudant klaidas, kol jos dar nepradėtos gaminti. Svarbiausia, kad testavimas padeda įgyti pasitikėjimo, kad kodas nesužlugs.
6. Rąstų svarba
Žurnalai yra naudingi derinant ir suprantant jūsų programos būseną. Jie suteikia vertingų įžvalgų apie programos elgseną. Čia pateikiamas trumpas sąrašas dalykų, kuriuos reikia nepamiršti sveriant žurnalus:
- Raskite tinkamą pusiausvyrą medienos ruošoje. Turėti „per daug informacijos“ niekada nėra blogai, tačiau per didelis registravimas tik apsunkins jūsų darbą. Spyglių lengviau rasti mažesniuose šieno kupetose. Kita vertus, dėl nepakankamo registravimo bus per mažai informacijos, kad būtų galima derinti ar diagnozuoti.
- Suskirstykite savo neprisijungus pasiekiamus ir internetinius žurnalus, kuriuose saugomi naujausi žurnalai, kad juos būtų galima greitai gauti ir apdoroti, o senesni žurnalai yra archyvuojami arba perkeliami į failus.
- Apsvarstykite savo žurnalų dažnumą ir trukmę, nes tai paveiks jums reikalingos saugyklos kiekį. Dažniausiai reikalingas saugyklos kiekis ir turimų žurnalų skaičius yra tiesiogiai proporcingi.
Atminkite, kad neprisiregistruokite neskelbtinų duomenų, tokių kaip el. Pašto ID, slaptažodžiai, kredito kortelės informacija ir telefono numeriai. Tai ne tik didžiulė saugumo rizika, bet ir dažnai neteisėta.
7. Ar taikymo mastas?
Blogiausias požiūris į programų kūrimą yra galvoti apie tai, kaip keisti mastelį po to jūs gaunate srautą. Vietoj to turėtumėte sukurti architektūrą, galinčią augti nuo pat pradžių, kad sutaupytumėte laiko ir padidintumėte produktyvumą.
Serverių sukūrimas nėra mastelio keitimas; paskirstyti krūvį ištekliams yra. Tai nereiškia, kad neturėtumėte sukurti naujų serverių, kai apkrova padidėja. Pirmiausia turėtumėte nustatyti apkrovos balansavimą pagal savo dabartinius išteklius, kad galėtumėte valdyti padidėjusią apkrovą. Kai apkrovos balansavimas negali efektyviai valdyti darbo krūvio, laikas pradėti horizontalų mastelį ir sukurti naujus serverius. Tai galite pasiekti per nepriklausomą procesą be pilietybės arba per modulius. Kiekvienas procesas ar modulis veiks izoliuotai, nepriklausomai. Tai ne tik padės efektyviai išplėsti jūsų programą, bet ir padarys jūsų sistemą atsparią gedimams ir lengvai atkuriamą.
Kaip struktūrizuoti žiniatinklio programą, yra taip pat svarbu, kaip pasirinkti tinkamą technologiją. Jei pamatai yra ydingi, programa ilgainiui sugrius, atsisakys mastelio arba kai kuriais atvejais apskritai nepavyks paleisti. Niekada neskubėkite kurti naujų funkcijų ar naujų idėjų be tinkamo planavimo ir architektūros. Bloga struktūra ar architektūra yra tarsi tiksinti bomba, laukianti sprogimo.
Naujųjų technologijų forumas suteikia galimybę tyrinėti ir aptarti besiformuojančios įmonės technologijas beprecedentiame gylyje. Atranka yra subjektyvi, atsižvelgiant į mūsų pasirinktas technologijas, kurios, mūsų manymu, yra svarbios ir labiausiai domina skaitytojus. nepriima rinkodaros užtikrinimo priemonės paskelbimui ir pasilieka teisę redaguoti visą pateiktą turinį. Visus klausimus siųskite adresu [email protected].
