Farðu aftur
Þessi þáttur var áætlaður til útgáfu í desember fyrir jólahléið, svo það lítur út fyrir að ég sé flöskuhálsinn sem beri ábyrgð á töfunni. Ég hef frestað útgáfunni viku eftir viku þar sem nokkur forgangsverkefni komu í veg, en í dag er sá dagur.
Hér er tómt.Í síðasta þætti gaf ég í skyn að ég myndi tjá mig um greinina sem fjallar um mikilvægi húmor á vinnustaðnum, en á meðan áttaði ég mig á því að hún á skilið mun meiri viðurkenningu, svo ég ætla að skrifa heila bloggfærslu um hana bráðlega (eða svo).
Það sem hélt mér upptekinni síðustu tvær vikur:
a) Fyrir jól hóf ég með frumsýningu á “Vefnámskeiðaröðin ”Bulletproof CTO" (Fylgist með öðrum þætti í febrúar sem mun sýna SaaS CTOs, smáatriði koma fljótlega á LinkedIn-síðu minni).
b) Að fínstilla vaxtaráætlun okkar fyrir 2021 með það að markmiði að fara fram úr okkar Rúbín og JS kjarnastarfsemi og vaxa a Magento og Vara Hönnunarkunnáttan innanhúss.
Nóg um sjálfsauglýsingu, leyfðu mér að bjóða þig velkominn í fimmtu þáttaröðina af #TheCodestReview.
Þemu mín lið hefur undirbúið sig fyrir þennan tíma:
Athugasemdir um frontend-forrit og hefðbundnar skuldbindingar eru afhentar þessa viku af okkar React verkfræðingar á meðan Ruby 3.0.0 af okkar Ruby draumi team.
Í dag nota margir forritarar, til að spara tíma, fyrirfram gerðar notendaviðmótsbókasöfn og endurnýtanlega íhluti. Þetta er góð venja og það hjálpar. okkur til að spara mikinn tíma en þegar okkar verkefni Verður stærra – þú munt skilja að það dugar ekki að takast á við það með kóði.
Það eru tvö góð mynstur úr bakendaþróun – sviðstýrð þróun (Domain Driven Development, DDD) og aðskilnaður ábyrgða (Separation of Concerns, SoC). Við getum einnig notað þau í framendaarkitektúr.
Í DDD reynum við að flokka svipuð einkenni saman og aftengja þau eins mikið og mögulegt er frá öðrum hópum (einingum).
Þegar við notum SoC aðskiljum við til dæmis rökfræði, sýn og gagnalíkön (t.d. með því að nota MVC- eða MVVM-hönnunarmynstur).
Það eru margar góðar aðferðir og mynstur sem hægt er að nota, en þessi leið hentar mér best.
Þegar við notum þetta mynstur fáum við þessa mynd:
Í upphafi er notandinn beint í réttan mótulið með leiðsögn forritsins. Hvert mótulið er algjörlega sjálfstætt. En þar sem notandi gerir ráð fyrir að nota eitt forrit, ekki nokkur smáforrit, verður til ákveðin tenging. Þessi tenging snýr að tilteknum eiginleikum eða viðskiptalógík.
Og við höfum þessa uppbyggingu:
forritamappa – forritalag
auðlindir – möppu fyrir myndir, letur, táknin o.s.frv.
Þættir – hér ættu að vera endurnýtanlegir þættir sem ekki hafa flókna rökfræði.
config – hér munum við geyma alríkisástand
lib – möppu fyrir flókin fall og rökfræðiútreikninga
einingar – hér eru einingar okkar
pubsub – staður til að geyma skema til að lýsa gögn uppbygging.
Stílar – fyrir CSS/SCSS-kóðann okkar
Þessi uppbygging mun hjálpa okkur að takast á við vaxandi forritið okkar og hafa færri villur. Einnig mun hún gera vinnuna þægilegri með því að skipta kóðanum upp í aðskilda eininga, prófa þá og auðvelda endurskipulagningu og villuleit (vegna aðskildra eininga).
Ef við skoðum nánar móduulauppbyggingu og tengsl þeirra við forritaskil – við munum fá eitthvað svona:
Ef við búum til ‘app’-möppu munum við búa til aðra möppu, ‘api’, með kóða fyrir API-köll og gögn sem við geymum í ‘config/store’. Hér geymum við kyrrstæð og óbreytanleg gögn sem við notum í allri forritinu.
Einnig í möppunni ‘pubsub/schema’ munum við lýsa sértækum gagnategundum fyrir JavaScript hlutir.
Allir módelar innihalda gögn sem við þurfum að nota (notendur, leiðir, töflur, aðgerðir o.s.frv.). Hver módel tengist forritalagi og sækir öll nauðsynleg gögn.
Framenda er fyrsti inngangspunktur notenda okkar. Þegar framsendaverkefni okkar bætast við fleiri eiginleikum munum við einnig koma inn fleiri villur. En notendur okkar gera ekki ráð fyrir villum og vilja nýja eiginleika hratt. Þetta er ómögulegt. En með því að nota góða arkitektúr getum við aðeins reynt að ná þessu eins mikið og mögulegt er.
Ímyndaðu þér að þú sért á upphafspunkti hjá fyrirtæki sem þú varst nýráðinn til. Allir eru vingjarnlegir við þig og allt virðist vera í lagi þar til þú kynnist kóðagrunni sem var til áður en JavaScript var forritunarmál og Netscape var að hlaða síðu sem virtist taka eilífð.
Arfgengi kóða virðist vera gríðarlegt vandamál þegar nýir forritarar koma inn í verkefni. Að lesa kóðann er eitt, en að skilja hvernig forritið var þróað er ekki alveg það sama. Oft reynast skráningar (commits) gagnlegar og veita samhengi um hvers vegna þessar console.log-skilaboð voru ekki greindar af linter eða hvers vegna það leiðinlega // TODO er þar fyrir börn forritarans sem setti athugasemdirnar upphaflega.
Byrjum á því hvers vegna hefðbundnar skuldbindingar eru betri en óstaðlaðar reglur um skuldbindingar.
Ef við ráðum nýja forritara í verkefni þar sem flestar breytingaskráningar samanstanda af skilaboðum á borð við "þetta ætti að virka" eða "Sleepy, lagaðu fótinn sem fyrst", hvað dettur þér í hug?
Ég myndi segja að þetta væru viðvörunarmerki vegna:
Vegna þess að team þínum er hægt að beita sérsniðnum reglum þegar breytingar eru gerðar er minna svigrúm fyrir mistök þar sem skuldbindingin þín þarf að vera traust. Þetta er ekki lengur bara leið til að sækja útgáfu. Þetta er undirskrift sem segir öðrum að þú hafir þekkt innihald skuldbindingarinnar. Það þarf ekki að nefna að ef verkið sem þú hefur unnið er ekki rétt undirritað mun það líklega leiða til villu og birta þér skilaboð.
Það er möguleiki á að team þinn vilji setja upp reglu sem bannar ákveðin lykilorð, svo ASAP eða önnur bölvunarorð geti verið á svörtum lista.
Það sem er virkilega hjálplegt í upphafi verkefnisins er að kynna fyrir öllum hvernig þitt dev team Mig langar til að sjá nýja þróunaraðila skrá breytingar sínar. Síðan setjið upp tól sem hjálpar þeim að fylgja því sem þið öll sammældust um.
Eitt af þeim verkfærum sem ég hef haft tækifæri til að vinna með var commitlint og það gerði hefðbundnar committanir að mínum helsta vinnubrögðum þegar ég tek að mér ný verkefni sem hafa engin reglur, og team er opinn fyrir þeirri hugmynd að setja þær inn.
Þegar þú ert að fást við stillingarnar og dreifa þeim um team-ið þitt geturðu einfaldlega búið til npm-pakka og mpn i -D það í hverju verkefni. Þetta mun án efa hjálpa öllum í verkefninu að vera á sama máli hvenær sem er og, ef þörf krefur, færa sig milli verkefna með skilning á því hvaða síðustu breytingar voru gerðar (og af hverju).
Nú þegar allt er komið upp og þú skilur hvers vegna það gæti verið góð hugmynd að byrja að nota CC, væri það skemmtilegasta að forrita í kringum reglurnar sem þú hefur nýlega beitt! Við notum staðlaða aðferð við commits, við veitum meiri athygli á því hvað commit-ið raunverulega fjallaði um, svo af hverju ekki að setja upp hooks sem gera þér kleift að prófa fljótt á staging þegar flag er til staðar? Við viljum ekki yfirbyrða þjónustur og viljum geta skorið niður kostnað þegar þörf krefur, og það eru nokkrar ástæður til að prófa á framleiðslu-líkum netþjóni frekar en á localhost.
Segjum sem svo að þú sért að vinna að PWA og þurfir SSL til að prófa alla möguleika þess, og þú hafir SSL á prófunarumhverfi þínu. Nú þarftu bara góða committun. Eitthvað á borð við feat(PWA): manifest icons workbox setup upload myndi kveikja á allri vélprófuninni og færa tannhjól í gang. Við þurfum það ekki þegar við erum bara að hlaða upp kyrrstæðum gögnum eins og manifest.json, svo við bætum við fánanum [TEST_SKIP] sem viðhengisviðskeyti við commit-ið okkar. Þetta gerir CI-kerfinu okkar kleift að hlaða einfaldlega nýjum auðlindum upp í prófunarumhverfið og sleppa prófunum. Þú getur lesið meira um það hér
Eftir smá stund munt þú geta séð aðra kosti, svo sem auðvelda framleiðslu CHANGELOG og betri útgáfustjórnun með semantískt útgáfukerfi. Ef það dugar ekki til að sannfæra þig um að breyta vinnubrögðum þínum við að skrifa skýrsluskilaboð, gæti það að dýfa tám þínum í fersku, kalda vatni og prófa að nota þau í einkasafni þínu um tíma breytt hug þínum.
Gleðilegt hefðbundið skuldbindingu!
Langþráða útgáfan Ruby 3.0.0 hefur loksins litið dagsins ljós um jólin svo að allir Ruby-þróunaraðilar geti fundið hana undir jólatrénu þegar þeir vakna um morguninn. Á The Codest Við ræktum menningu þekkingardeilingar með því að skipuleggja vikulega þróunarfundi þar sem verkfræðingar okkar ræða tæknitrend og nýjar uppgötvanir sem vert er að huga að. Hér fyrir neðan er hlekkur á glærur frá kynningardegi þar sem eldri Ruby-verkfræðingur okkar fjallaði um nokkrar mikilvægar breytingar í Ruby 3.0.0 frá eigin sjónarhorni:
https://drive.google.com/file/d/1rboAusV1UTWXYMVGuLHx6O90lXrgkmnO/view?usp=sharing
Ennfremur hefur Ruby-mentorinn okkar lagt sitt af mörkum til nýrrar útgáfu með pull-beiðni sinni sem var farsællega sameinuð. Meira um aðferðir til að stjórna persónuvernd má finna hér að neðan í stuttri grein frá þróunarstjóra okkar.
https://thecodest.co/blog/ruby-3-0-ruby-and-lesser-known-privacy-control-methods
Takk kærlega fyrir að lesa, og ef þú hefur komist svona langt, þakka ég þér fyrir tímann. Allar athugasemdir eru meira en vel þegnar á LinkedIn eða á netfangið mitt.
Við komum aftur til ykkar með næsta þátt í lok febrúar með yfirferð á hlaðvarpi sem tók viðtal við Shopify's CTO, maðurinn á bak við verkfræðinginn team sem vinnur að hinni stórkostlegu Ruby Monolith-forritinu!
Sjáumst síðar.
Lesa meira:
TheCodestReview #4 – vikulegur hugbúnaðarverkfræði-safi
Icelandic 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Polish 
Arabic 
Italian 
Spanish 
Dutch 
Estonian 
Greek 
Portuguese 
Czech 
Latvian 
Lithuanian