TAGASI
See episood oli kavas avaldada detsembris enne jõulupuhkust, nii et tundub, et mina olen see kitsaskoht, kes on süüdi viivituses. Ma olen avaldamist nädalate kaupa edasi lükanud, sest mõned tähtsamad ülesanded on takerdunud, kuid täna on see päev.
Viimases episoodis olen kiusanud kommenteerima artiklit, mis käsitleb huumori tähtsust töökohal, kuid vahepeal sain aru, et see väärib palju rohkem tunnustust, nii et kirjutan sellest varsti terve blogipostituse(ish).
Asjad, mis mind viimase paari nädala jooksul hõivatud on:
a) Enne jõule alustasin ma esietendusega episoodi "Kuulikindel CTO" veebiseminaride sari (jääge ootama veebruaris toimuvat 2. episoodi, mis hõlmab SaaSi CTOs, üksikasjad järgnevad peagi minu LinkedInis).
b) Meie kasvuplaani häälestamine aastaks 2021 eesmärgiga minna kaugemale meie Ruby ja JS põhitegevusest ning kasvatada Magento ja Toode Konstrueerimisalane pädevus majasisene.
Piisab enesereklaamimisest, lubage mul kutsuda teid meie #TheCodestReview sarja 5. episoodi.
Teemad minu meeskond on selleks ajaks ette valmistatud:
Kommentaarid frontendirakenduse ja tavapäraste kommitsuste kohta on sel nädalal esitanud meie React insenerid, samas kui Ruby 3.0.0 on toimetanud meie Ruby dream team.
Tänapäeval kasutavad paljud arendajad aja kokkuhoiu eesmärgil juba tehtud kasutajaliidese raamatukogusid ja korduvkasutatavaid komponente. See on hea tava ja aitab meil palju aega kokku hoida, kuid kui meie projekt muutub suuremaks - saate aru, et see ei ole piisav, et hakkama saada koos kood.
On kaks head mustrit back-end arendusest - domeenipõhine arendus (DDD) ja probleemide lahutamine (SoC). Me saame seda kasutada ka front-end arhitektuuris.
DDD-s püüame rühmitada sarnaseid funktsioone ja lahutada need võimalikult palju teistest rühmadest (moodulitest).
SoC puhul eraldame näiteks loogika, vaated ja andmemudelid (nt MVC või MVVM disainimustrit kasutades).
On palju häid tavasid ja mustreid, mida kasutada, kuid see viis on minu jaoks eelistatud.
Kui me kasutame seda mustrit, saame sellise pildi:
Alguses suunatakse kasutaja rakenduse marsruutimise abil õigesse moodulisse. Iga moodul on täielikult suletud. Kuid kuna kasutaja ootab, et ta kasutaks ühte rakendust, mitte mitut väikest, siis tekib mõningane sidumine. See haakumine esineb konkreetsete funktsioonide või äriloogika puhul.
Ja meil on selline struktuur:
app kaust - rakenduskihi
varad - kaust piltide, fontide, ikoonide jne jaoks.
komponendid - siin peaksid olema taaskasutatavad komponendid, millel ei ole keerulist loogikat
config - siin salvestame globaalse oleku
lib - kaust keeruliste funktsioonide ja loogika arvutamise jaoks
moodulid - siin on meie moodulid
pubsub - koht andmete struktuuri kirjeldamise skeemide salvestamiseks.
stiilid - meie css/scss koodi jaoks
See struktuur aitab meil toime tulla meie kasvava rakendusega ja vähendada vigu. Samuti aitab see teha mugavamalt töötavaid osi eraldi moodulitega, testida neid ja teha refaktooring ja silumine lihtsamaks (eraldi moodulite tõttu).
Kui me vaatame sügavamalt moodulite arhitektuuri ja nende seoseid API-ga - saame midagi sellist:
Kui 'app' kausta loome teise kausta 'api' koodiga API-kutsete ja andmete jaoks, mida salvestame 'config/store'. Siin hoiame staatilisi ja muutumatuid andmeid, mida kasutame kogu rakenduses.
Kaustas 'pubsub/schema' kirjeldame ka konkreetseid andmetüüpe, mis on mõeldud JavaScript esemed.
Kõik moodulid sisaldavad andmeid, mida me peame kasutama (kasutajad, marsruudid, tabelid, tegevused jne). Iga moodul on ühendatud rakenduskihiga ja võtab kõik vajalikud andmed.
Front-end on meie kasutajate jaoks esimene sisenemiskoht. Kuna meie front-end-projektide funktsioonid kasvavad, siis lisame ka rohkem vigu. Kuid meie kasutajad ootavad, et vigu ei oleks ja et uued funktsioonid tuleksid kiiresti. See on võimatu. Ometi saame hea arhitektuuri abil püüda seda võimalikult palju saavutada.
Kujutage ette, et olete alguspunktis ettevõttes, kuhu teid just tööle võeti. Kõik inimesed on teiega toredad ja kõik tundub olevat hästi kuni hetkeni, mil teile tutvustatakse koodibaasi, mis pärineb ajast, mil JavaScript oli veel keel ja Netscape laadis lehekülge, mis tundus olevat terve igavik.
Koodipärimine näib olevat suur probleem uute arendajate tutvustamisel projektis. Koodi lugemine on üks asi, kuid arusaamine, kuidas rakendus on välja töötatud, ei ole päris sama. Sageli osutuvad commits kasulikuks ja annavad konteksti, miks need console.logid linteriga kinni ei jäänud või miks see vastik // TODO on seal selle arendaja laste jaoks, kes algselt selle märkuse tegi.
Alustame sellest, miks tavapärased kommiteerimised on paremad kui standardimata kommiteerimisreeglid.
Kui me palkame uusi arendajaid projekti, kus enamik kommiteid koosneb sõnumitest stiilis see peaks töötama või Sleepy fix for footer ASAP, mis teile pähe tuleb?
Ma ütleksin, et punased lipud, sest:
Kuna teie meeskonnal on võimalik kohaldada kohandatud reegleid, millal keegi muudatusi teeb, siis on vähem ruumi vigadele, kuna teie pühendumine peab olema kindel. See ei ole enam võimalus lihtsalt välja vaadata. See on allkiri, mis ütleb teistele inimestele, et te teadsite commit'i sisu. Pole vaja mainida, et kui teie tehtud töö ei ole korrektselt allkirjastatud, siis tõenäoliselt tekib viga ja teile tuleb teade
On võimalus, et teie meeskond soovib kehtestada reegli, mis keelab teatud märksõnade kasutamise, nii et ASAP või mis tahes sõimusõnad võivad olla mustas nimekirjas.
Projekti alguses on tõesti kasulik tutvustada kõigile, kuidas teie arendusmeeskond sooviksid näha uusi arendajaid, kes oma muudatused kinnitaksid. Siis seadistage tööriist, mis aitab neil hoida end kursis sellega, milles te kõik kokku leppisite.
Üks tööriistadest, millega mul oli võimalus töötada, oli commitlint ja see muutis tavapärased kommitid minu tavaks, kui ma tulen uute projektidega, millel ei ole reegleid ja meeskond on avatud nende kasutuselevõtu ideele.
Seadistustega tegelemisel ja nende levitamisel oma meeskonnas võite lihtsalt luua npm-paketi ja lihtsalt mpn i -D seda igas projektis. See aitab kindlasti kõigil projektis olevatel inimestel olla alati ühel lainel ja vajadusel kõndida projektist projekti ja mõista, mis olid viimased muudatused (ja miks need tehti).
Nii et nüüd, pärast seda, kui olete kõik üles seadnud ja mõistnud, miks võiks olla hea mõte hakata CC-d kasutama, oleks parim osa programmeerimine nende reeglite ümber, mida te just rakendasite! Me kasutame standardiseeritud viisi, kuidas me pühendume, me pöörame rohkem tähelepanu sellele, mida commit tegelikult oli, nii et miks mitte luua konksud, mis võimaldavad teil kiiret testimist staging'is, kui lipp on olemas? Me ei taha üle koormata teenuseid ja kärpida kulusid, kui see on vajalik, ja on mõned põhjused testida production-like serveris, mitte localhostis.
Oletame, et te töötate PWAga ja SSL on vajalik, et saaksite testida kogu potentsiaali ja teil on oma testimisplatvormil SSL. Nüüd on vaja vaid head commit'i. Midagi stiilis feat(PWA): manifest icons workbox setup upload käivitaks kogu testimise ja hammasrataste liigutamise masinavärgi. Me ei vaja seda, kui lihtsalt laadime üles mõned staatilised andmed nagu manifest.json, nii et lisame lipu [TEST_SKIP] postfixina meie commitile. See võimaldab meie CI-l lihtsalt uusi varasid testimiskeskkonda üles laadida ja testimise vahele jätta. Selle kohta saate lugeda rohkem siin
Mõne aja pärast näete ka muid kasumeid, nagu näiteks CHANGELOGi loomise lihtsus ja parem versioonimine koos semantiline versioonimine. Kui sellest ei piisa, et veenda teid muutma oma viisid pühendunud sõnumite kirjutamisel, siis võib-olla muudab teie meelt see, kui te kastate oma varbad värskesse külma vette ja proovite neid mõnda aega oma privaatses repositooriumis kasutada.
Õnnelik tavapärastele kohustustele pühendumist!
Kaua oodatud kogukonna Ruby 3.0.0 versioon on jõulude ajal ilmunud, nii et kõik Ruby arendajad leiavad selle jõulupuu alt, kui nad hommikul ärkavad. Me The Codest-s viljeleme teadmiste jagamise kultuuri, korraldades iganädalasi arenduskohtumisi, kus meie insenerid arutavad tehnoloogiatrende ja oma uusi avastusi, mis väärivad tähelepanu. Allpool leiate lingi demopäeva slaididele, kus meie vanem Ruby insener arutas paar olulist muudatust Ruby 3.0.0-s oma subjektiivsest vaatenurgast:
https://drive.google.com/file/d/1rboAusV1UTWXYMVGuLHx6O90lXrgkmnO/view?usp=sharing
Lisaks sellele on meie Ruby mentor andnud oma panuse uude versiooni oma pull request'iga, mis on edukalt ühendatud. Rohkem infot privaatsuskontrolli meetodite teemal leiate allpool meie arendusjuhi lühikesest artiklist.
https://thecodest.co/blog/ruby-3-0-ruby-and-lesser-known-privacy-control-methods
Suur tänu lugemise eest ja kui olete jõudnud nii kaugele, siis hindan teie aega ja iga tagasiside on rohkem kui teretulnud LinkedInis või minu e-postile.
Järgmise episoodiga tuleme teile tagasi veebruari lõpus, kus vaatame läbi podcasti, milles intervjueeritakse Shopify CTO, meest, kes töötab suurepärase Ruby monoliitrakenduse kallal inseneritiimi taga!
Kohtumiseni.
Loe edasi:
TheCodestReview #4 - iganädalane tarkvaratehnika mahl
Estonian 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Polish 
Arabic 
Italian 
Japanese 
Korean 
Spanish 
Dutch 
Greek