Rahul Mhatre on tekninen arkkitehti Built.iossa.
Node.js on nopeasti kiinni Java, Ruby, Python ja .Net ensisijaisena kielenä uusien verkkosovellusten kehittämiseen. Node.js-tiimi tekee JavaScriptien ajonaikasta paremman, nopeamman ja vakaamman joka päivä. Ja käyttäjäyhteisö kasvaa nopeasti.
Kun käyttöönotto jatkuu, yhä useammat kehittäjät kiipeävät Node.js-oppimiskäyrää kohtaamalla samanlaisia ongelmia ja koodaamalla samanlaisia toimintoja. Onneksi Node.js-yhteisö on tullut apuun kehyksillä ja suunnittelumalleilla, jotka paitsi ratkaisevat yleisiä ongelmia myös auttavat sovellusten jäsentämisessä.
Kehykset toteuttavat yleensä MV-malleja, kuten MVC (malli-näkymä-ohjain), MVVM (malli-näkymä-näkymä-malli), MVP (malli-näkymä-esittäjä) tai vain MV. Ne kertovat myös, missä mallien, näkymien ja ohjaimien koodin pitäisi olla, missä reittien tulisi olla ja mihin sinun tulisi lisätä kokoonpanosi. Monet nuoret kehittäjät ja Node.js-harrastajat eivät oikeastaan ymmärrä, kuinka suunnittelumallit tai OOP (Object Oriented Programming) -kaaviot kartoittavat sovelluksen koodin viivat tai rakenteen.
Sieltä tulevat Node.js-kehykset, kuten Express.js ja Sails.js. Nämä ja monet muut ovat käytettävissä auttamaan käynnistämään verkkosovellusten kehittäminen. Käyttämästäsi kehyksestä riippumatta sinun on pidettävä mielessä tietyt näkökohdat sovellusta jäsennettäessä.
Tässä on seitsemän avainkohtaa, jotka ajattelen ennen Node.js-sovelluksen kartoittamista.
1. Sovelluksen oikea hakemistorakenne
Kun päätät sovelluksesi hakemistorakenteesta, sinun on otettava huomioon valitsemasi suunnittelumalli. Tämä auttaa aloittamista, koodin löytämistä ja ongelmien eristämistä nopeammin. Pidän mieluummin MVC-mallin käyttämisestä Node.js-sovelluksen suunnittelussa. Se auttaa minua kehittymään nopeammin, tarjoaa joustavuutta luoda useita näkymiä samoille tiedoille ja mahdollistaa asynkronisen viestinnän ja eristämisen MVC-komponenttien välillä, muutamia mainitakseni.
Haluan seurata yllä esitettyä hakemistorakennetta, joka perustuu Ruby on Rails ja Express.js -yhdistelmiin.
Liittyvä video: Node.js-vinkkejä ja vihjeitä
Opi tässä selitysvideossa useita tekniikoita, jotka voivat parantaa Node-kehityskokemustasi.
2. ER-kaavioiden yhdistäminen malleihin
Kuten Techopediassa on määritelty, "Entiteettisuhdekaavio (ERD) on tietomallinnustekniikka, joka kuvaa graafisesti tietojärjestelmän entiteettejä ja näiden yksiköiden välisiä suhteita." ER-kaavio kuvaa erilaisia entiteettejä, jotka osallistuvat järjestelmäämme, ja määrittelee kaikki niiden väliset vuorovaikutukset siten, että:
- Kaikesta, mikä on abstrakti tai fyysinen "asia", tulee mallin kokonaisuus
- Malli kartoittaa tietokantamme sisällä olevaan taulukkoon
- Kokonaisuuden attribuutti tai ominaisuus kääntyy mallin attribuutiksi, joka puolestaan on sarake taulukon sisällä
Esimerkiksi, jos entiteettisi on käyttäjä, vastaava malli olisi "Käyttäjä", jolla on määritteet, kuten etunimi, sukunimi ja osoite tietokannassa, sekä vastaava taulukko ja sarakkeet.
Yksinkertaisen dataarkkitehtuurin käyttäminen tekee tietokannan ja tiedostojen kasvun seuraamisesta melko suoraviivaista aina, kun uusi skeema luodaan.
3. Käytä MVP-mallia
MVC: n käyttöönotto ei tarkoita vain kansioiden luomista ohjaimille, näkymille ja malleille. Sinun on myös jaettava koodi ja logiikka MVC: n mukaan. Malliesi sisällä olevan koodin tulisi olla tiukasti rajoitettu tietokantamallin määrittelyihin. Kehittäjät unohtavat yleensä, että malleissa on myös koodi, joka suorittaa CRUD-operaatiot. Myös kaikkien kyseiselle mallille ominaisen toiminnon tai operaation tulisi olla tämän tiedoston sisällä. Suurimman osan malliin liittyvästä liiketoimintalogiikasta pitäisi olla tässä tiedostossa.
Yleinen virhe on, että kaikki liiketoimintalogiikat viedään ohjaimiin. Ohjainten tulisi kutsua toimintoja vain malleista tai muista komponenteista, siirtää tietoja komponenttien välillä ja hallita pyynnön kulkua, kun taas näkymäkansiossa tulisi olla vain koodi, jolla objektit voidaan muuntaa luettavaksi. Näkymän sisällä ei tule tehdä mitään logiikkaa, kuten tietojen muotoilua tai lajittelua tai suodatusta. Näkymien pitäminen puhtaina ei vain paranna käyttökokemusta, vaan myös auttaa sinua vaihtamaan näkymiä muuttamatta muita komponentteja.
4. Logiikan jakaminen moduuleiksi
Kehittäjinä meille aina sanotaan, että meidän tulisi järjestää koodi tiedostoiksi ja moduuleiksi. Tämä ei tarkoita sitä, että meidän pitäisi yrittää sovittaa koko sovellus yhteen tiedostoon. Koodin jakaminen logiikan ja toiminnallisuuden perusteella on paras tapa. Yksittäiseen kokonaisuuteen tai objektiin liittyvien toimintojen ryhmitteleminen yhteen tiedostoon ja hakemistorakenteen järjestämiseen logiikan perusteella on monia etuja. Ensinnäkin se säästää paljon aikaa kosketuksen määrittämiseen, kun virhe on korjattava. Toiseksi se auttaa irrottamaan kaikki arkkitehtuurin komponentit, mikä helpottaa erillisten toimintojen korvaamista tarvitsematta muuttaa muita koodirivejä. Kolmanneksi se auttaa myös testitapausten kirjoittamisessa.
5. Testitapausten merkitys
On erittäin tärkeää, ettet koskaan leikkaa kulmia testitapauksia rakennettaessa - testit ovat koodikannan vartijoita. Kun sovelluksesi kasvaa, on vaikea muistaa kaikkia skenaarioita, jotka sinun on käsiteltävä koodaamisen aikana. Testitapaukset auttavat pitämään koodipohjan vakaana. Testaus estää regressiota ja säästää arvokasta kehitysaikaa ja vaivaa. Se auttaa varmistamaan, että uudet ominaisuudet siirretään virheettömästi. Se auttaa myös parantamaan koodin laatua tarttumalla virheisiin ennen kuin ne menevät tuotantoon. Ja mikä tärkeintä, testaus auttaa lisäämään luottamusta siihen, että koodi ei kaatu.
6. Tukkien merkitys
Lokit ovat hyödyllisiä virheenkorjauksessa ja sovelluksen tilan ymmärtämisessä. Ne tarjoavat arvokasta tietoa sovelluksen toiminnasta. Tässä on lyhyt luettelo asioista, jotka on pidettävä mielessä lokien hyödyntämisessä:
- Löydä oikea tasapaino puunkorjuun suhteen. "Liian paljon tietoa" ei ole koskaan huono, mutta ylikirjaaminen vain vaikeuttaa työsi. Neuloja on helpompi löytää pienemmistä heinäsuovista. Kääntöpuolelta puuttuva kirjaaminen johtaa liian vähän tietoja virheenkorjaukseen tai diagnosointiin.
- Jaa offline- ja online-lokit, jolloin uusimmat lokit pidetään nopeaa hakua ja käsittelyä varten, kun taas vanhemmat lokit arkistoidaan tai tallennetaan tiedostoihin.
- Ota huomioon lokisi tiheys ja kesto, koska se vaikuttaa tarvitsemasi tallennustilan määrään. Useimmiten tarvitsemasi tallennustilan määrä ja lokien lukumäärä ovat suoraan verrannollisia.
Muista, että älä kirjaa arkaluontoisia tietoja, kuten sähköpostitunnuksia, salasanoja, luottokorttitietoja ja puhelinnumeroita. Se ei ole vain valtava turvallisuusriski, vaan usein laiton.
7. Määritetäänkö sovelluksen mittakaava?
Pahin lähestymistapa sovelluskehitykseen on ajatella skaalausta jälkeen saat liikennettä. Sen sijaan sinun tulisi rakentaa arkkitehtuuri, jolla on kyky kasvaa alusta alkaen säästääkseen aikaa ja lisätä tuottavuutta.
Palvelinten pyörittäminen ei ole skaalaus; kuorman jakaminen resurssien kesken on. Tämä ei tarkoita, että sinun ei pitäisi luoda uusia palvelimia kuormituksen kasvaessa. Ensinnäkin sinun on määritettävä kuormituksen tasapainottaminen nykyisissä resursseissasi käsittelemään lisääntynyttä kuormaa. Kun kuormituksen tasapainottaminen ei pysty hallitsemaan työmäärää tehokkaasti, on aika aloittaa vaakasuuntainen skaalaus ja luoda uusia palvelimia. Voit saavuttaa tämän itsenäisellä valtiottomalla prosessilla tai moduulien avulla. Jokainen prosessi tai moduuli toimii eristetyllä, itsenäisellä tavalla. Tämä ei vain auta sovellustasi tehokkaasti, vaan myös tekee järjestelmästä vikasietoista ja helposti palautettavissa.
Verkkosovelluksen rakentaminen on yhtä tärkeää kuin oikean tekniikan valitseminen. Jos perustukset ovat puutteelliset, sovellus kaatuu lopulta tai kieltäytyy mittakaavasta tai joissakin tapauksissa ei käynnisty lainkaan. Älä koskaan kiirehdi uusien ominaisuuksien tai uusien ideoiden kehittämiseen ilman asianmukaista suunnittelua ja arkkitehtuuria. Huono rakenne tai arkkitehtuuri on kuin tikittävä aikapommi, joka odottaa räjähtämistä.
New Tech Forum tarjoaa mahdollisuuden tutkia ja keskustella kehittyvistä yritysteknologioista ennennäkemättömällä syvyydellä ja laajuudella. Valinta on subjektiivinen, perustuu valitsemiemme tekniikoihin, joiden uskomme olevan tärkeitä ja kiinnostavia lukijoille. ei hyväksy markkinointivakuuksia julkaisua varten ja pidättää oikeuden muokata kaikkea lähetettyä sisältöä. Lähetä kaikki tiedustelut osoitteeseen [email protected].
