PALAA TAAKSE
Tämä jakso oli tarkoitus julkaista joulukuussa ennen joulutaukoa, joten näyttää siltä, että minä olen se pullonkaula, joka on syypää viivästymiseen. Olen lykännyt julkaisua viikko viikolta, kun muutamat tärkeät tehtävät ovat tulleet tielle, mutta tänään on se päivä.
Viime jaksossa olen kiusoitellut kommentoimaan artikkelia, joka käsittelee huumorin merkitystä työpaikoilla, mutta sillä välin tajusin, että se ansaitsee paljon enemmän tunnustusta, joten aion kirjoittaa siitä pian kokonaisen blogikirjoituksen.
Asiat, jotka pitivät minut kiireisenä parin viime viikon aikana:
a) Ennen joulua aloitin ensi-iltajaksolla sarjan "Luodinkestävä CTO" -webinaarisarja (pysy kuulolla helmikuun 2. jaksoa varten, jossa on SaaS:ää CTO:t, lisätietoja pian LinkedInissäni).
b) Kasvusuunnitelmamme virittäminen vuodelle 2021, jonka tavoitteena on mennä Ruby- ja JS-ydinliiketoimintamme ulkopuolelle ja kasvattaa Magento- ja Tuote Suunnitteluosaaminen sisäinen.
Tarpeeksi itsemainontaa, haluan kutsua sinut #TheCodestReview-sarjamme viidenteen jaksoon.
Aiheet minun joukkue on valmistautunut tähän aikaan:
Kommentit frontend-sovelluksesta ja tavanomaisista kommitoinneista toimitetaan tällä viikolla React-insinööreiltämme, kun taas Ruby 3.0.0:n toimittaa Ruby dream team -tiimimme.
Nykyään monet kehittäjät käyttävät ajan säästämiseksi jo valmiita käyttöliittymäkirjastoja ja uudelleenkäytettäviä komponentteja. Se on hyvä käytäntö, ja se auttaa meitä säästämään paljon aikaa, mutta kun meidän projekti tulee suurempi - ymmärrät, että se ei riitä käsittelemään kanssa koodi.
Back-end-kehityksestä on olemassa kaksi hyvää mallia - Domain Driven Development (DDD) ja Separation of Concerns (SoC). Voimme käyttää niitä myös front-end-arkkitehtuurissa.
DDD:ssä yritämme ryhmitellä samankaltaisia ominaisuuksia ja irrottaa ne mahdollisimman paljon muista ryhmistä (moduuleista).
SoC:n avulla esimerkiksi logiikka, näkymät ja tietomallit erotetaan toisistaan (esimerkiksi MVC- tai MVVM-suunnittelumallin avulla).
On olemassa paljon hyviä käytäntöjä ja malleja, mutta tämä tapa on minulle mieluisin.
Kun käytämme tätä mallia, saamme tämän kuvan:
Sovelluksen reititys ohjaa käyttäjän alussa oikeaan moduuliin. Jokainen moduuli on täysin suljettu. Mutta koska käyttäjä odottaa käyttävänsä yhtä sovellusta eikä useita pieniä sovelluksia, on olemassa jonkin verran kytkentää. Tämä kytkentä liittyy tiettyihin ominaisuuksiin tai liiketoimintalogiikkaan.
Ja meillä on tämä rakenne:
app-kansio - sovelluskerros
assets - kansio kuvia, fontteja, kuvakkeita jne. varten.
komponentit - tässä pitäisi olla uudelleenkäytettäviä komponentteja, joissa ei ole monimutkaista logiikkaa.
config - tänne tallennetaan globaali tila
lib - kansio monimutkaisille funktioille ja logiikkalaskennalle
moduulit - tässä ovat moduulit
pubsub - paikka, johon tallennetaan tietorakennetta kuvaavia skeemoja.
styles - css/scss-koodillemme
Tämä rakenne auttaa meitä käsittelemään kasvavaa sovellustamme ja vähentämään virheitä. Se auttaa myös tekemään helpommin erillisiä moduuleja, testaamaan niitä ja tekemään refaktoroinnista ja virheenkorjauksesta helpompaa (erillisten moduulien ansiosta).
Jos tarkastelemme tarkemmin moduulien arkkitehtuuria ja niiden yhteyksiä API:n kanssa, saamme jotakin tämän kaltaista:
Jos 'app'-kansio luodaan toinen kansio 'api', jossa on API-kutsujen koodi ja tiedot tallennetaan 'config/store'-kansioon. Tässä säilytämme staattisia ja muuttumattomia tietoja, joita käytämme koko sovelluksessa.
Myös 'pubsub/schema'-kansiossa kuvataan erityiset tietotyypit seuraaville tiedostoille JavaScript esineitä.
Kaikki moduulit sisältävät tietoja, joita meidän on käytettävä (käyttäjät, reitit, taulukot, toiminnot jne.). Jokainen moduuli on yhteydessä sovelluskerrokseen ja ottaa kaikki tarvittavat tiedot.
Front-end on ensimmäinen kohta, josta käyttäjät pääsevät sisään. Kun front-end-projektimme ominaisuudet lisääntyvät, myös virheitä tulee lisää. Käyttäjämme odottavat kuitenkin, ettei virheitä esiinny ja että uudet ominaisuudet tulevat nopeasti. Tämä on mahdotonta. Käyttämällä hyvää arkkitehtuuria voimme kuitenkin vain yrittää saavuttaa tämän mahdollisimman hyvin.
Kuvittele, että olet lähtötilanteessa yrityksessä, johon olet juuri saanut työpaikan. Kaikki ihmiset ovat mukavia sinulle, ja kaikki näyttää hyvältä siihen asti, kunnes pääset tutustumaan koodipohjaan, joka on peräisin ajalta ennen kuin JavaScript oli kieli ja Netscape latasi sivua ikävältä tuntuvan ajan.
Koodin periytyminen näyttää olevan valtava ongelma, kun uusia kehittäjiä otetaan mukaan projektiin. Koodin lukeminen on yksi asia, mutta sen ymmärtäminen, miten sovellus on kehitetty, ei ole aivan sama asia. Usein kommitit osoittautuvat hyödyllisiksi ja antavat kontekstin sille, miksi linter ei saanut kiinni näitä console.logeja tai miksi tuo ikävä // TODO on siellä sen kehittäjän lapsille, joka alun perin teki merkinnän.
Aloitetaan siitä, miksi tavanomaiset komennot ovat parempia kuin standardoimattomat komentosäännöt.
Jos palkkaamme uusia kehittäjiä projektiin, jossa suurin osa kommitoinneista koostuu viesteistä tyyliin tuon pitäisi toimia tai Sleepy fix for footer ASAP, mitä tulee mieleesi?
Sanoisin, että punainen lippu, koska:
Koska tiimisi voi soveltaa mukautettuja sääntöjä siihen, milloin joku tekee muutoksia, on vähemmän tilaa virheille, koska toimituksen on oltava vankka. Se ei ole enää keino, jolla voi vain kirjautua ulos. Se on allekirjoitus, joka kertoo muille ihmisille, että tiesit toimituksen sisällön. Ei tarvitse mainita, että jos tekemääsi työtä ei ole allekirjoitettu oikein, se johtaa todennäköisesti virheeseen ja antaa sinulle viestin
On mahdollista, että tiimisi haluaisi asettaa säännön, joka kieltää tietyt avainsanat, joten ASAP tai kirosanat voivat olla mustalla listalla.
Projektin alussa on todella hyödyllistä esitellä kaikille, miten teidän kehitystiimi haluaisi uusien kehittäjien sitoutuvan muutoksiinsa. Perustakaa sitten työkalu, joka auttaa heitä pitämään kiinni siitä, mitä te kaikki olette sopineet.
Yksi työkalu, jonka kanssa minulla on ollut mahdollisuus työskennellä, oli commitlint ja se teki tavanomaisista kommitoinneista käytäntöni, kun tulen uusiin projekteihin, joissa ei ole sääntöjä ja joissa tiimi on avoin ajatukselle niiden käyttöönotosta.
Kun käsittelet asetuksia ja levität niitä tiimisi kesken, voit yksinkertaisesti luoda npm-paketin ja vain mpn i -D sen jokaiseen projektiin. Tämä auttaa varmasti kaikkia projektin jäseniä olemaan aina samalla sivulla ja tarvittaessa kävelemään projektista toiseen ymmärtäen, mistä viimeisimmät muutokset johtuivat (ja miksi ne tehtiin).
Nyt kun olet asettanut kaiken valmiiksi ja ymmärtänyt, miksi CC:n käyttäminen voisi olla hyvä idea, paras osa on ohjelmointi juuri soveltamiesi sääntöjen ympärille! Käytämme standardoitua tapaa, jolla teemme committeja, kiinnitämme enemmän huomiota siihen, mistä commitissa todella oli kyse, joten miksi emme asettaisi koukkuja, jotka mahdollistavat nopean testauksen stagingissä, kun lippu on läsnä? Emme halua ylikuormittaa palveluita ja leikata kustannuksia tarvittaessa, ja on joitakin syitä testata tuotantoa muistuttavalla palvelimella localhostin sijaan.
Oletetaan, että työskentelet PWA:n parissa ja että SSL on tarpeen, jotta voit testata sen koko potentiaalia, ja sinulla on SSL testausalustassasi. Tarvitset nyt vain hyvän sitoumuksen. Jotain tyyliin feat(PWA): manifest icons workbox setup upload käynnistäisi koko testauksen koneiston ja hammasrattaiden liikuttelun. Emme tarvitse sitä, kun vain lataamme jotain staattista dataa, kuten manifest.jsonin, joten lisäämme flagin [TEST_SKIP] postfixina commitiin. Sen ansiosta CI:mme voi vain ladata uusia assetteja testausympäristöön ja ohittaa testauksen. Voit lukea lisää siitä täällä
Jonkin ajan kuluttua voit nähdä muita hyötyjä, kuten CHANGELOGin luomisen helppous ja parempi versiointi, kun käytät semanttinen versiointi. Jos tämä ei riitä vakuuttamaan sinua muuttamaan tapojasi kirjoittaa commit-viestejä, ehkäpä varpaiden kastaminen raikkaaseen kylmään veteen ja niiden käyttäminen yksityisessä arkistossasi jonkin aikaa muuttaisi mielesi.
Hyvää perinteistä sitoutumista!
Kauan odotettu Ruby 3.0.0 -julkaisu on nähnyt päivänvalon jouluna, jotta kaikki Ruby-kehittäjät löytäisivät sen joulukuusen alta, kun he heräävät aamulla. Me The Codest:ssä vaalimme tiedon jakamisen kulttuuria järjestämällä viikoittaisia dev-kokouksia, joissa insinöörimme keskustelevat teknologiatrendeistä ja uusista huomionarvoisista löydöistään. Alta löydät linkin demopäivän dioihin, joissa vanhempi Ruby-insinöörimme käsitteli subjektiivisesta näkökulmastaan pari tärkeää Ruby 3.0.0:n muutosta:
https://drive.google.com/file/d/1rboAusV1UTWXYMVGuLHx6O90lXrgkmnO/view?usp=sharing
Lisäksi Ruby-mentorimme on osallistunut uuteen versioon vetopyynnöllään, joka yhdistettiin onnistuneesti. Lisää yksityisyydenhallintamenetelmistä löydät kehitysjohtajamme lyhyestä artikkelista.
https://thecodest.co/blog/ruby-3-0-ruby-and-lesser-known-privacy-control-methods
Kiitos paljon lukemisesta, ja jos olet tullut näin pitkälle, arvostan aikaasi, ja jokainen palaute on enemmän kuin tervetullutta LinkedInissä tai sähköpostiini.
Palataan seuraavaan jaksoon helmikuun lopussa podcastin arvostelulla, jossa haastatellaan Shopifyn CTO:tä, miestä, joka on upean Ruby-monoliitti-sovelluksen parissa työskentelevän insinööritiimin takana!
Nähdään taas.
Lue lisää:
TheCodestReview #4 - viikoittainen ohjelmistotekniikan mehu
Finnish 
English 
German 
Swedish 
Danish 
Norwegian 
French 
Arabic 
Italian 
Japanese 
Korean 
Polish