GÅ TILBAGE
Denne episode var planlagt til udgivelse i december før juleferien, så det ser ud til, at jeg er flaskehalsen, der er skyld i forsinkelsen. Jeg er blevet ved med at udskyde udgivelsen uge for uge, da et par højt prioriterede opgaver kom i vejen, men i dag er dagen.
I sidste episode drillede jeg med at kommentere artiklen om vigtigheden af humor på arbejdspladsen, men i mellemtiden har jeg fundet ud af, at den fortjener meget mere anerkendelse, så jeg vil snart skrive et helt blogindlæg om den (ish).
Ting, der har holdt mig beskæftiget de sidste par uger:
a) Før jul startede jeg med premiereafsnittet af "Skudsikker CTO"-webinarserie (hold øje med 2. episode i februar med SaaS) CTO'er(detaljer følger snart på min LinkedIn).
b) Justering af vores vækstplan for 2021 med et mål om at gå ud over vores Ruby og JS-kerneforretning og udvikle en Magento- og Produkt Designkompetence internt.
Nok om selvpromovering, lad mig invitere dig til 5. episode af vores #TheCodestReview-serie.
Mine emner hold har forberedt sig på denne tid:
Kommentarerne til frontend-applikationen og konventionelle commits leveres i denne uge af vores React-ingeniører, mens Ruby 3.0.0 leveres af vores Ruby-dreamteam.
I dag bruger mange udviklere allerede fremstillede UI-biblioteker og genanvendelige komponenter for at spare tid. Det er en god praksis, og det hjælper os med at spare en masse tid, men når vores projekt bliver større - du vil forstå, at det ikke er nok at håndtere med Kode.
Der er to gode mønstre fra backend-udvikling - Domain Driven Development (DDD) og Separation of Concerns (SoC). Vi kan også bruge dem i front-end-arkitekturen.
I DDD forsøger vi at gruppere lignende funktioner og afkoble dem så meget som muligt fra andre grupper (moduler).
Mens vi med SoC f.eks. adskiller logik, visninger og datamodeller (f.eks. ved hjælp af MVC- eller MVVM-designmønsteret).
Der er mange gode fremgangsmåder og mønstre at bruge, men denne måde er at foretrække for mig.
Når vi bruger dette mønster, får vi dette billede:
I begyndelsen bliver brugeren omdirigeret til det korrekte modul af app-routingen. Hvert modul er fuldstændig lukket. Men da en bruger forventer at bruge én applikation og ikke et par små, vil der være en vis kobling. Denne kobling findes på specifikke funktioner eller forretningslogik.
Og vi har denne struktur:
app-mappe - applikationslag
assets - mappe til billeder, skrifttyper, ikoner osv.
komponenter - her skal være komponenter til genbrug, som ikke har kompliceret logik
config - her gemmer vi den globale tilstand
lib - mappe til komplicerede funktioner og logiske beregninger
moduler - her er vores moduler
pubsub - sted til opbevaring af skemaer til beskrivelse af datastrukturer.
styles - til vores css/scss-kode
Denne struktur vil hjælpe os med at håndtere vores voksende applikation og få færre fejl. Det vil også gøre det nemmere at arbejde med separate moduler, at teste dem og at gøre refaktorering og fejlfinding lettere (på grund af de separate moduler).
Hvis vi ser nærmere på modularkitekturen og deres forbindelser med API'er, får vi noget i den retning:
I mappen 'app' opretter vi en anden mappe 'api' med kode til API-opkald og data, som vi gemmer i 'config/store'. Her opbevarer vi statiske og uforanderlige data, som vi bruger i hele applikationen.
I mappen 'pubsub/schema' vil vi også beskrive specifikke datatyper for JavaScript objekter.
Alle moduler indeholder data, som vi skal bruge (brugere, ruter, tabeller, handlinger osv.). Hvert modul er forbundet med applikationslaget og tager alle nødvendige data.
Front-end er den første indgang for vores brugere. Når vores frontend-projekter får flere funktioner, vil vi også introducere flere fejl. Men vores brugere forventer ingen fejl og nye funktioner hurtigt. Det er umuligt. Men ved at bruge en god arkitektur kan vi kun forsøge at opnå dette så meget som muligt.
Forestil dig, at du er ved at starte i en virksomhed, hvor du lige er blevet ansat. Alle folk er søde ved dig, og alt virker fint, indtil du bliver introduceret til en kodebase fra før JavaScript var et sprog, og Netscape indlæste en side i noget, der virker som en evighed.
Nedarvning af kode synes at være et stort problem, når nye udviklere skal introduceres til et projekt. At læse koden er én ting, men at forstå, hvordan applikationen blev udviklet, er ikke helt det samme. Ofte viser commits sig at være nyttige og giver kontekst til, hvorfor disse console.logs ikke blev fanget af linter, eller hvorfor den grimme // TODO er der for børn af den udvikler, der oprindeligt lavede annotationen.
Lad os starte med at fortælle, hvorfor konventionelle commits er bedre end ustandardiserede commit-regler.
Hvis vi ansætter nye udviklere til et projekt, hvor de fleste commits består af beskeder i stil med "det burde virke" eller "Sleepy fix for footer ASAP", hvad dukker så op i dit hoved?
Jeg vil sige, at der er røde flag, fordi:
Fordi dit team kan have tilpassede regler for, hvornår man overfører ændringer, er der mindre plads til fejl, da din overførsel skal være solid. Det er ikke længere bare en måde at tjekke ud på. Det er en signatur, der fortæller andre mennesker, at du kendte indholdet af committen. Det er ikke nødvendigt at nævne, at hvis det arbejde, du har udført, ikke er korrekt signeret, vil det højst sandsynligt resultere i en fejl og give dig en besked
Der er en chance for, at dit team gerne vil opsætte en regel, der forbyder bestemte nøgleord, så ASAP eller bandeord kan komme på den sorte liste.
Det, der virkelig hjælper i starten af projektet, er at introducere alle til, hvordan din Udviklingsteam vil gerne have nye udviklere til at committe deres ændringer. Sæt derefter et værktøj op, der hjælper dem med at holde trit med det, I alle er blevet enige om.
Et af de værktøjer, jeg har haft mulighed for at arbejde med, var commitlint og det gjorde konventionelle commits til min go-to-praksis, når jeg kommer til nye projekter, der ikke har regler, og teamet er åbent over for ideen om at indføre dem.
Når du skal håndtere indstillingerne og sprede dem på tværs af dit team, kan du simpelthen oprette en npm-pakke og bare mpn i -D den i hvert projekt. Det vil helt sikkert hjælpe alle i projektet med at være på samme side hele tiden og om nødvendigt gå fra projekt til projekt og forstå, hvad de sidste ændringer drejede sig om (og hvorfor de blev foretaget).
Så efter at have sat det hele op og forstået, hvorfor det kan være en god idé at begynde at bruge CC, er den bedste del at programmere omkring de regler, du lige har anvendt! Vi bruger en standardiseret måde at committe på, vi er mere opmærksomme på, hvad committen egentlig handlede om, så hvorfor ikke opsætte hooks, der giver dig mulighed for hurtig testning på staging, når der er et flag til stede? Vi ønsker ikke at overbelaste tjenesterne og skære ned på omkostningerne, når det er nødvendigt, og der er nogle grunde til at teste på en produktionslignende server i stedet for localhost.
Lad os antage, at du arbejder på PWA, og at SSL er nødvendigt for at teste det fulde potentiale, og at du har en SSL på din testplatform. Alt, hvad du behøver nu, er bare en god commit. Noget i retning af feat(PWA): manifest icons workbox setup upload ville udløse hele maskineriet med test og flytte rundt på tandhjulene. Det har vi ikke brug for, når vi bare uploader nogle statiske data som manifest.json, så vi tilføjer et flag [TEST_SKIP] som et postfix til vores commit. Det gør det muligt for vores CI bare at uploade nye aktiver til testmiljøet og springe testningen over. Du kan læse mere om det her
Efter et stykke tid vil du kunne se andre fordele, som f.eks. at det er nemmere at generere CHANGELOG og bedre versionering med semantisk versionering. Hvis det ikke er nok til at overbevise dig om at ændre din måde at skrive commit-beskeder på, kan det måske få dig på andre tanker at dyppe tæerne i frisk, koldt vand og prøve at bruge dem i dit private repository i et stykke tid.
God fornøjelse med at begå konventionelle handlinger!
En længe ventet Ruby 3.0.0-udgivelse har set dagens lys i julen, så alle Ruby-udviklere derude kunne finde den under juletræet, når de vågnede om morgenen. Hos The Codest dyrker vi vidensdelingskulturen ved at organisere ugentlige udviklingsmøder, hvor vores ingeniører diskuterer teknologitendenser og deres nye opdagelser, der er værd at lægge mærke til. Nedenfor kan du finde et link til slides fra demodagen, hvor vores senior Ruby-ingeniør diskuterede et par vigtige ændringer i Ruby 3.0.0 fra sit subjektive synspunkt:
https://drive.google.com/file/d/1rboAusV1UTWXYMVGuLHx6O90lXrgkmnO/view?usp=sharing
Desuden har vores Ruby-mentor bidraget til den nye version med sin pull-anmodning, som blev flettet med succes. Du kan læse mere om metoder til kontrol af privatlivets fred i den korte artikel af vores udviklingschef nedenfor.
https://thecodest.co/blog/ruby-3-0-ruby-and-lesser-known-privacy-control-methods
Mange tak, fordi du læste med, og hvis du er kommet så langt, sætter jeg pris på din tid, og enhver form for feedback er mere end velkommen på LinkedIn eller på min e-mail.
Vi vender tilbage med den næste episode i slutningen af februar med en gennemgang af en podcast, der interviewer Shopifys CTO, manden bag et ingeniørteam, der arbejder på den storslåede Ruby-monolit-app!
Vi ses.
Læs mere om det:
TheCodestReview #4 - ugentlig software engineering juice
Danish 
English 
German 
Swedish 
Norwegian 
Finnish 
French 
Polish 
Arabic 
Italian 
Japanese 
Korean 
Spanish 
Dutch 
Estonian 
Greek