TheCodestReview #5 - dvisavaitinės programinės įrangos inžinerijos sultys

Paskutiniame epizode aš užsiminiau, kad pakomentuosiu straipsnį apie humoro svarbą darbe, bet tuo tarpu supratau, kad jis nusipelno daug daugiau dėmesio, todėl netrukus apie tai parašysiu visą tinklaraščio įrašą.    

Dalykai, kuriais buvau užsiėmęs per pastarąsias porą savaičių: 

a) Prieš Kalėdas aš pradėjau su premjera epizodas “Neperšaunamas CTO” internetinių seminarų serija (sekite vasario mėn. 2-ąjį epizodą, kuriame bus SaaS CTOs, išsami informacija netrukus bus pateikta mano "LinkedIn" paskyroje).

b) mūsų 2021 m. augimo plano derinimas, siekiant viršyti mūsų Ruby ir JS pagrindinį verslą ir auginti Magento ir Produktas Dizaino kompetencija vidinis.

Pakanka savireklamos, leiskite pakviesti jus į 5-ąjį mūsų #TheCodestReview serijos epizodą. 

Temos mano komanda pasiruošė šiam laikui: 

1. keičiamo mastelio ir prižiūrima priekinės dalies architektūra.
2. Įprastiniai įsipareigojimai.
3. "Ruby 3.0.0" išleidimo atnaujinimai.

Šią savaitę pristatytos pastabos dėl frontend programos ir įprastinių pakeitimų. React inžinieriai o Ruby 3.0.0 mūsų Ruby svajonė team.

Šiandien daug kūrėjų, taupydami laiką, naudoja jau sukurtas vartotojo sąsajos bibliotekas ir daugkartinio naudojimo komponentus. Tai gera praktika ir padeda mus sutaupyti daug laiko, bet kai mūsų projektas tampa didesnis - suprasite, kad nepakanka tvarkyti su kodas.

Yra du geri pavyzdžiai iš galinės dalies kūrimo - domeno valdomas kūrimas (angl. Domain Driven Development, DDD) ir interesų atskyrimas (angl. Separation of Concerns, SoC). Juos taip pat galime naudoti priekinės dalies architektūroje.

DDD sistemoje stengiamės sugrupuoti panašias funkcijas ir kuo labiau atskirti jas nuo kitų grupių (modulių).

Pavyzdžiui, naudojant SoC atskiriame logiką, vaizdus ir duomenų modelius (pvz., naudojant MVC arba MVVM projektavimo modelį).

Yra daug geros praktikos ir modelių, kuriuos galima naudoti, tačiau man priimtinesnis šis būdas.

Kai naudosime šį modelį, gausime tokį vaizdą:

Pradžioje naudotojas nukreipiamas į reikiamą modulį pagal programėlės maršruto parinkimą. Kiekvienas modulis yra visiškai uždaras. Tačiau kadangi naudotojas tikisi naudotis viena programa, o ne keliomis mažomis, tam tikras susiejimas egzistuoja. Šis susiejimas yra susijęs su konkrečiomis funkcijomis arba verslo logika.

Turime šią struktūrą:

programų aplankas - taikomųjų programų sluoksnis

assets - aplankas paveikslėliams, šriftams, piktogramoms ir t. t.

komponentai - čia turėtų būti pakartotinai naudojami komponentai, neturintys sudėtingos logikos.

config - čia saugosime visuotinę būseną

lib - sudėtingų funkcijų ir loginių skaičiavimų aplankas

moduliai - čia yra mūsų moduliai

pubsub - aprašymo schemų saugojimo vieta duomenys struktūra.

stiliai - mūsų css/scss kodui

Tokia struktūra padės mums tvarkyti augančią programą ir turėsime mažiau klaidų. Be to, ji padės patogiau kurti darbo dalis su atskirais moduliais, juos testuoti ir lengviau refaktorizuoti bei derinti (dėl atskirų modulių).

Jei giliau pažvelgsime į modulių architektūrą ir jų sąsajas su API - gausime kažką panašaus:

Jei aplankas ‘app’, sukursime kitą aplanką ‘api’, kuriame bus API skambučių kodas, o duomenis išsaugosime aplanke ‘config/store’. Čia laikysime statiškus ir nekintamus duomenis, kuriuos naudosime visoje programoje.

Taip pat aplanke ‘pubsub/schema’ aprašysime konkrečius duomenų tipus, skirtus JavaScript objektai.

Visuose moduliuose yra duomenų, kuriuos reikia naudoti (vartotojai, maršrutai, lentelės, veiksmai ir t. t.). Kiekvienas modulis yra sujungtas su taikomuoju sluoksniu ir priima visus reikiamus duomenis.

Priekinė dalis yra pirmasis mūsų naudotojų prieigos taškas. Kadangi mūsų "Front-end" projektuose daugėja funkcijų, atsiras ir daugiau klaidų. Tačiau mūsų naudotojai tikisi, kad klaidų nebus, o naujų funkcijų atsiras greitai. Tai neįmanoma. Tačiau naudodami gerą architektūrą galime tik stengtis tai kiek įmanoma pasiekti.

Įprastiniai įsipareigojimai pagal Sathyabodh Mudhol at DZone

Priežastis, dėl kurios reikia geriau atlikti darbą

Įsivaizduokite, kad esate pradiniame etape įmonėje, kurioje ką tik įsidarbinote. Visi žmonės su jumis maloniai bendrauja ir viskas atrodo gerai iki to momento, kai jums pristatoma kodų bazė, sukurta dar prieš tai, kai JavaScript buvo kalba, o "Netscape" įkeldavo puslapį, kuris atrodė kaip amžius.

Atrodo, kad kodo paveldėjimas yra didžiulė problema, kai su projektu supažindinami nauji kūrėjai. Vienas dalykas yra skaityti kodą, tačiau suprasti, kaip programa buvo sukurta, yra ne visai tas pats. Dažnai pasirodo, kad įsipareigojimai yra naudingi ir suteikia kontekstą, kodėl šie console.logs nebuvo sugauti linter arba kodėl tas nemalonus // TODO yra ten kūrėjo, kuris iš pradžių sukūrė anotaciją, vaikams.

Pradėkime nuo to, kodėl įprastiniai įsipareigojimai yra geresni už nestandartizuotas įsipareigojimo taisykles.

Jei samdome naujus kūrėjus į projektą, kuriame dauguma pakeitimų susideda iš pranešimų apie tai, kad turėtų veikti arba Sleepy fix for footer ASAP, kas pasirodo jūsų galvoje?

Sakyčiau, kad raudonos vėliavos, nes:

• Nežinome, kas tiksliai turėtų veikti
• Kodėl kažkas kažką stumtelėjo būdamas mieguistas ir galimai suklydęs?
• Ar pataisymas buvo skubotas, jei matome ASAP anotaciją?

Kadangi jūsų team gali būti taikomos pasirinktinės taisyklės, kai vienas įsipareigoja pakeitimus, yra mažiau vietos klaidoms, nes jūsų įsipareigojimas turi būti patikimas. Tai nebėra būdas tiesiog išsiregistruoti. Tai parašas, kuriuo kitiems žmonėms pasakoma, kad žinojote įsipareigojimo turinį. Nereikia nė minėti, kad jei atliktas darbas nėra tinkamai pasirašytas, greičiausiai bus padaryta klaida ir jums bus pateiktas pranešimas

Gali būti, kad jūsų team norės nustatyti taisyklę, draudžiančią naudoti tam tikrus raktinius žodžius, todėl ASAP arba bet kokie keiksmažodžiai gali būti įtraukti į juodąjį sąrašą.

Įrankiai

Projekto pradžioje labai naudinga visus supažindinti su tuo, kaip jūsų kūrėjų komanda norėtų, kad nauji kūrėjai įsipareigotų atlikti pakeitimus. Tada sukurkite įrankį, kuris padėtų jiems laikytis to, dėl ko visi susitarėte.

Vienas iš įrankių, su kuriuo teko dirbti, buvo commitlint dėl to įprastiniai įsipareigojimai tapo mano praktika, kai pradedu dirbti su naujais projektais, kuriuose nėra taisyklių, o team yra atviras idėjai jas įvesti.

Susidurdami su nustatymais ir skleisdami juos team galite tiesiog sukurti npm paketą ir tiesiog mpn i -D kiekviename projekte. Tai neabejotinai padės visiems projekto dalyviams visada būti tame pačiame lape ir prireikus vaikščioti iš vieno projekto į kitą, suprantant, dėl ko buvo padaryti paskutiniai pakeitimai (ir kodėl jie buvo padaryti).

Draugai su keliais privalumais

Taigi dabar, viską sukūrus ir supratus, kodėl gali būti gera idėja pradėti naudoti CC, geriausia būtų programuoti pagal ką tik pritaikytas taisykles! Mes naudojame standartizuotą būdą, kaip mes perduodame duomenis, daugiau dėmesio skiriame tam, dėl ko iš tikrųjų buvo perduotas pranešimas, tad kodėl gi nenustačius kabliukų, kurie leistų jums greitai išbandyti staging, kai yra vėliava? Nenorime perkrauti paslaugų ir prireikus sumažinti išlaidas, be to, yra keletas priežasčių testuoti į gamybą panašiame serveryje, o ne localhost.

Tarkime, kad dirbate su PWA, o norint išbandyti visas jos galimybes, reikia SSL ir savo bandymų platformoje turite SSL. Dabar jums reikia tik gero įsipareigojimo. Kažkas panašaus į feat(PWA): manifest icons workbox setup upload įjungtų visą testavimo ir krumpliaračių judinimo mechanizmą. Mums to nereikia, kai tiesiog įkeliame tam tikrus statinius duomenis, pavyzdžiui, manifest.json, todėl prie savo įsipareigojimo pridedame vėliavėlę [TEST_SKIP] kaip postfiksą. Tai leidžia mūsų CI tiesiog įkelti naujus išteklius į testavimo aplinką ir praleisti testavimą. Apie tai galite paskaityti daugiau čia

Po kurio laiko galėsite pastebėti kitą naudą, pvz., lengvesnį CHANGELOG generavimą ir geresnį versijų kūrimą naudojant semantinis versijų kūrimas. Jei to neužtenka, kad įtikintumėte pakeisti savo įsipareigojimų pranešimų rašymo būdus, galbūt jūsų nuomonę pakeis tai, jei įmerksite pirštus į šaltą vandenį ir kurį laiką pabandysite juos naudoti savo asmeninėje saugykloje.

Laimingas tradicinis įsipareigojimas!

"Ruby 3.0.0" išleidimo atnaujinimai pagal Ruby bendruomenė

Bendruomenėje ilgai laukta "Ruby 3.0.0" versija išvydo dienos šviesą per Kalėdas, kad visi "Ruby" kūrėjai galėtų ją rasti po Kalėdų eglute, kai tik atsibus ryte. Tinklalapyje The Codest puoselėjame dalijimosi žiniomis kultūrą organizuodami kassavaitinius programuotojų susitikimus, kuriuose mūsų inžinieriai aptaria technologijų tendencijas ir naujus dėmesio vertus atradimus. Žemiau rasite nuorodą į demonstracinės dienos skaidres, kuriose mūsų vyresnysis "Ruby" inžinierius aptarė keletą svarbių "Ruby 3.0.0" pakeitimų savo subjektyviu požiūriu:

https://drive.google.com/file/d/1rboAusV1UTWXYMVGuLHx6O90lXrgkmnO/view?usp=sharing

Be to, mūsų "Ruby" mentorius prisidėjo prie naujosios versijos, pateikdamas traukimo užklausą, kuri buvo sėkmingai sujungta. Daugiau informacijos apie privatumo kontrolės metodus rasite toliau pateiktame trumpame mūsų plėtros vadovo straipsnyje.

https://thecodest.co/blog/ruby-3-0-ruby-and-lesser-known-privacy-control-methods

Labai ačiū, kad skaitote, ir jei nuėjote taip toli, esu dėkingas už jūsų laiką, o kiekvienas atsiliepimas yra daugiau nei laukiamas "LinkedIn" arba mano el. paštu.

Grįžtame pas jus su kitu epizodu vasario pabaigoje su podkasto apžvalga, kurioje bus apklausiamas Shopify's CTO, žmogus už inžinerijos team, dirbantis su nuostabia "Ruby" monolito programa!

Iki pasimatymo.

Skaityti daugiau:

TheCodestReview #4 - savaitinės programinės įrangos inžinerijos sultys

TheCodestReview #3 - savaitinės programinės įrangos inžinerijos sultys

TheCodestReview #2 - savaitinės programinės įrangos inžinerijos sultys