TheCodestReview #5 - software engineering juice annenhver uke

I forrige episode har jeg teaset for å kommentere artikkelen om viktigheten av humor på arbeidsplassen, men i mellomtiden har jeg funnet ut at den fortjener mye mer ros, så jeg kommer til å skrive et helt blogginnlegg om den snart (ish).    

Ting som har holdt meg opptatt de siste par ukene: 

a) Før jul startet jeg med premiereepisoden av Webinarserien "Skuddsikker CTO" (følg med på 2. episode i februar med SaaS CTO-er(detaljer følger snart på LinkedIn).

b) Justere vekstplanen vår for 2021 med et mål om å gå utover kjernevirksomheten vår innen Ruby og JS og utvide Magento og Produkt Designkompetanse internt.

Nok selvpromotering, la meg invitere deg til den femte episoden av vår #TheCodestReview-serie. 

Mine temaer team har forberedt for denne tiden: 

1. Skalerbar og vedlikeholdbar frontend-arkitektur.
2. Konvensjonelle forpliktelser.
3. Ruby 3.0.0 oppdateringer.

Kommentarene til frontend-applikasjonen og konvensjonelle commits leveres denne uken av våre React-ingeniører, mens Ruby 3.0.0 leveres av vårt Ruby dream team.

I dag er det mange utviklere som bruker ferdige UI-biblioteker og gjenbrukbare komponenter for å spare tid. Det er en god praksis, og det hjelper oss med å spare mye tid, men når våre prosjekt blir større - du vil forstå at det ikke er nok å håndtere med kode.

Det finnes to gode mønstre fra backend-utvikling - domenedrevet utvikling (DDD) og Separation of Concerns (SoC). Vi kan også bruke dem i frontend-arkitektur.

I DDD prøver vi å gruppere like funksjoner og frikoble dem så mye som mulig fra andre grupper (moduler).

Med SoC skiller vi for eksempel mellom logikk, visninger og datamodeller (f.eks. ved hjelp av MVC- eller MVVM-designmønsteret).

Det finnes mange gode fremgangsmåter og mønstre å bruke, men denne måten er å foretrekke for meg.

Når vi bruker dette mønsteret, får vi dette bildet:

I begynnelsen blir brukeren omdirigert til riktig modul ved hjelp av app-rutingen. Hver modul er fullstendig lukket. Men ettersom en bruker forventer å bruke én applikasjon, ikke flere små, vil det være en viss kobling. Denne koblingen gjelder spesifikke funksjoner eller forretningslogikk.

Og vi har denne strukturen:

app-mappe - applikasjonslag

assets - mappe for bilder, skrifter, ikoner osv.

komponenter - her bør det være komponenter for gjenbruk som ikke har komplisert logikk

config - her lagrer vi global tilstand

lib - mappe for kompliserte funksjoner og logikkberegninger

moduler - her er modulene våre

pubsub - sted for lagring av skjemaer for beskrivelse av datastrukturer.

stiler - for css/scss-koden vår

Denne strukturen vil hjelpe oss med å håndtere en voksende applikasjon og redusere antall feil. Det vil også bidra til å gjøre det enklere å arbeide med separate moduler, teste dem og gjøre refaktorering og feilsøking enklere (på grunn av separate moduler).

Hvis vi ser nærmere på modularkitekturen og deres forbindelser med API - vil vi få noe sånt:

I "app"-mappen oppretter vi en annen mappe, "api", med kode for API-kall og data som vi lagrer i "config/store". Her lagrer vi statiske og uforanderlige data som vi bruker i hele applikasjonen.

I mappen "pubsub/schema" vil vi også beskrive spesifikke datatyper for JavaScript gjenstander.

Alle moduler inneholder data som vi trenger å bruke (brukere, ruter, tabeller, handlinger osv.). Hver modul er koblet til applikasjonslaget og tar alle nødvendige data.

Frontend er det første inngangspunktet for brukerne våre. Etter hvert som frontend-prosjektene våre får flere funksjoner, vil vi også introdusere flere feil. Men brukerne våre forventer ingen feil, og nye funksjoner raskt. Dette er umulig. Ved å bruke en god arkitektur kan vi likevel bare prøve å oppnå dette så langt det er mulig.

Konvensjonelle forpliktelser av Sathyabodh Mudhol på DZone

Årsaken til behovet for å forplikte arbeidet på en bedre måte

Tenk deg at du er i startfasen i et selskap du nettopp har blitt ansatt i. Alle er hyggelige mot deg, og alt virker bra helt til du blir introdusert til en kodebase fra før JavaScript var et språk og Netscape lastet inn en side i noe som virker som en evighet.

Nedarving av kode ser ut til å være et stort problem når nye utviklere skal introduseres til et prosjekt. Å lese koden er én ting, men å forstå hvordan applikasjonen ble utviklet er ikke helt det samme. Ofte viser det seg at commits er nyttige og gir kontekst til hvorfor disse console.loggene ikke ble fanget opp av linter, eller hvorfor den ekle // TODO-en er der for barn av utvikleren som opprinnelig lagde annotasjonen.

La oss begynne med å forklare hvorfor konvensjonelle commits er bedre enn ustandardiserte commit-regler.

Hvis vi ansetter nye utviklere til et prosjekt der de fleste commits består av meldinger i retning av "det bør fungere" eller "Sleepy fix for footer ASAP", hva dukker da opp i hodet ditt?

Jeg vil si at det er røde flagg fordi:

• Vi vet ikke nøyaktig hva som skal fungere
• Hvorfor har noen trykket på noe mens de var søvnige og potensielt feilaktige?
• Var løsningen forhastet hvis vi kan se ASAP-kommentaren?

Fordi teamet ditt kan ha egendefinerte regler for når endringer skal overføres, er det mindre rom for feil, ettersom forpliktelsen må være solid. Det er ikke lenger en måte å bare sjekke ut på. Det er en signatur som forteller andre at du kjente til innholdet i commiten. Det er ikke nødvendig å nevne at hvis arbeidet du har gjort ikke er korrekt signert, vil det mest sannsynlig resultere i en feil og du vil få en melding

Det er en mulighet for at teamet ditt ønsker å sette opp en regel som ikke tillater visse nøkkelord, slik at ASAP eller banneord kan stå på svartelisten.

Verktøy

Det som virkelig er nyttig i starten av prosjektet, er å introdusere alle for hvordan din utviklingsteam ønsker at nye utviklere skal forplikte endringene sine. Sett deretter opp et verktøy som hjelper dem med å holde tritt med det dere alle har blitt enige om.

Et av verktøyene jeg har hatt mulighet til å jobbe med, er commitlint og det har gjort konvensjonelle commits til min foretrukne praksis når jeg kommer til nye prosjekter som ikke har regler, og teamet er åpent for ideen om å innføre dem.

Når du håndterer innstillingene og sprer dem på tvers av teamet ditt, kan du ganske enkelt opprette en npm-pakke og bare mpn i -D den i hvert prosjekt. Det vil helt sikkert hjelpe alle i prosjektet til å være på samme side til enhver tid og om nødvendig gå fra prosjekt til prosjekt og forstå hva de siste endringene dreide seg om (og hvorfor de ble gjort).

Venner med flere fordeler

Så etter å ha satt det hele opp og forstått hvorfor det kan være en god idé å begynne å bruke CC, vil den beste delen være å programmere rundt reglene du nettopp har brukt! Vi bruker en standardisert måte å committe på, vi legger mer vekt på hva committen egentlig handlet om, så hvorfor ikke sette opp hooks som gjør det mulig å teste raskt på staging når et flagg er til stede? Vi ønsker ikke å overbelaste tjenester og kutte kostnadene når det er nødvendig, og det er noen grunner til å teste på produksjonslignende server i stedet for localhost.

La oss anta at du jobber med PWA og at SSL er nødvendig for at du skal kunne teste ut det fulle potensialet, og at du har en SSL på testplattformen din. Alt du trenger nå er bare en god commit. Noe i retning av feat(PWA): manifest icons workbox setup upload ville utløse hele maskineriet med testing og flytting av tannhjul rundt. Vi trenger ikke det når vi bare laster opp noen statiske data som manifest.json, så vi legger til et flagg [TEST_SKIP] som et postfiks til vår commit. Det gjør at CI-en vår bare kan laste opp nye ressurser til testmiljøet og hoppe over testingen. Du kan lese mer om det her

Etter hvert vil du kunne se andre fordeler, som for eksempel enkel generering av CHANGELOG og bedre versjonering med semantisk versjonering. Hvis det ikke er nok til å overbevise deg om å endre måten du skriver forpliktende meldinger på, kan du kanskje ombestemme deg ved å dyppe tærne i friskt, kaldt vann og prøve å bruke dem i ditt private depot en stund.

God konvensjonell forpliktelse!

Oppdateringer av Ruby 3.0.0-utgivelsen av Ruby Community

En lenge etterlengtet Ruby 3.0.0-utgivelse har sett dagens lys i julen, slik at alle Ruby-utviklere der ute kan finne den under juletreet når de våkner om morgenen. Hos The Codest dyrker vi kunnskapsdelingskulturen ved å organisere ukentlige utviklingsmøter der våre ingeniører diskuterer teknologitrender og deres nye oppdagelser som er verdt oppmerksomheten. Nedenfor finner du en lenke til lysbilder fra demodagen der vår senior Ruby-ingeniør diskuterte et par viktige endringer i Ruby 3.0.0 fra sitt subjektive synspunkt:

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

I tillegg har vår Ruby-mentor bidratt til den nye versjonen med en pull-forespørsel som ble slått sammen. Mer om temaet personvernkontrollmetoder finner du nedenfor i en kort artikkel av vår utviklingssjef.

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

Tusen takk for at du har lest, og hvis du har kommet så langt, setter jeg pris på at du tar deg tid, og alle tilbakemeldinger er mer enn velkomne på LinkedIn eller på e-post.

Vi kommer tilbake til deg med neste episode i slutten av februar med gjennomgangen av en podcast der vi intervjuer Shopifys CTO, mannen bak et ingeniørteam som jobber med den fantastiske Ruby-monolittappen!

Vi ses.

Les mer om dette:

TheCodestReview #4 - ukentlig juice for programvareutvikling

TheCodestReview #3 - ukentlig juice for programvareutvikling

TheCodestReview #2 - ukentlig juice for programvareutvikling