TheCodestReview #5 - mjukvaruutvecklingsjuice varannan vecka

I förra avsnittet tänkte jag kommentera artikeln om vikten av humor på arbetsplatsen, men under tiden kom jag på att den förtjänar mycket mer beröm så jag ska skriva ett helt blogginlägg om den snart (ish).    

Saker som hållit mig sysselsatt under de senaste veckorna: 

a) Före jul inledde jag med ett premiäravsnitt av Webbinarieserien "Bulletproof CTO" (håll ögonen öppna för det andra avsnittet i februari som handlar om SaaS CTO:er, detaljer följer snart på min LinkedIn).

b) Justera vår tillväxtplan för 2021 med målet att gå utöver vår Ruby och JS-kärnverksamhet och utveckla en Magento- och Produkt Designkompetens internt.

Nog med självreklam, låt mig bjuda in dig till det 5: e avsnittet i vår #TheCodestReview-serie. 

Ämnen min Team har förberett sig för denna tid: 

1. Skalbar och underhållbar frontend-arkitektur.
2. Konventionella åtaganden.
3. Ruby 3.0.0 release uppdateringar.

Kommentarerna till frontend-applikationen och konventionella åtaganden levereras den här veckan av våra React-ingenjörer medan Ruby 3.0.0 av vårt Ruby-dreamteam.

Idag använder många utvecklare redan gjorda UI-bibliotek och återanvändbara komponenter för att spara tid. Det är en bra praxis och det hjälper oss att spara mycket tid men när vår projekt blir större - kommer du att förstå att det inte räcker med att hantera med kod.

Det finns två bra mönster från backend-utveckling - Domain Driven Development (DDD) och Separation of Concerns (SoC). Vi kan också använda dem i front-end-arkitekturen.

I DDD försöker vi gruppera liknande funktioner och frikoppla dem så mycket som möjligt från andra grupper (moduler).

Medan vi med SoC till exempel separerar logik, vyer och datamodeller (t.ex. med hjälp av designmönstret MVC eller MVVM).

Det finns många bra metoder och mönster att använda, men det här sättet är att föredra för mig.

När vi använder det här mönstret får vi den här bilden:

I början omdirigeras användaren till rätt modul genom app-routingen. Varje modul är helt fristående. Men eftersom en användare förväntar sig att använda en applikation, inte några små, kommer viss koppling att finnas. Denna koppling finns för specifika funktioner eller affärslogik.

Och vi har den här strukturen:

app-mapp - applikationslager

tillgångar - mapp för bilder, teckensnitt, ikoner etc.

komponenter - här bör finnas komponenter för återanvändning som inte har komplicerad logik

config - här lagrar vi global status

lib - mapp för komplicerade funktioner och logiska beräkningar

moduler - här är våra moduler

pubsub - plats för lagring av scheman för beskrivning av datastruktur.

styles - för vår css/scss-kod

Denna struktur kommer att hjälpa oss att hantera vår växande applikation och att få färre buggar. Det kommer också att göra det lättare att arbeta med separata moduler, att testa dem och att göra refaktorisering och felsökning enklare (tack vare separata moduler).

Om vi tittar djupare på modularkitekturen och deras kopplingar till API - får vi något liknande:

I mappen 'app' skapar vi en annan mapp 'api' med kod för API-anrop och data som vi sparar i 'config/store'. Här lagrar vi statiska och oföränderliga data som vi använder i hela applikationen.

I mappen "pubsub/schema" kommer vi också att beskriva specifika datatyper för JavaScript objekt.

Alla moduler innehåller data som vi behöver använda (användare, rutter, tabeller, åtgärder etc.). Varje modul är ansluten till applikationslagret och tar alla nödvändiga data.

Frontend är den första ingångspunkten för våra användare. I takt med att våra frontend-projekt får fler funktioner kommer vi också att introducera fler buggar. Men våra användare förväntar sig inga buggar och nya funktioner snabbt. Detta är omöjligt. Men genom att använda en bra arkitektur kan vi bara försöka uppnå detta så mycket som möjligt.

Konventionella åtaganden av Sathyabodh Mudhol på DZone

Anledningen till behovet av att engagera sig i arbetet på ett bättre sätt

Föreställ dig att du är vid en startpunkt i ett företag som du just har anställts av. Alla människor är trevliga mot dig och allt verkar bra fram till den punkt då du introduceras till en kodbas från innan JavaScript var ett språk och Netscape laddade en sida i vad som verkar vara en ålder.

Nedärvningen av kod verkar vara ett stort problem när nya utvecklare introduceras i ett projekt. Att läsa koden är en sak, men att förstå hur applikationen utvecklades är inte riktigt samma sak. Ofta visar sig commits vara användbara och ger sammanhang till varför dessa console.logs inte fångades upp av linter eller varför den otäcka // TODO finns där för barn till den utvecklare som ursprungligen gjorde annotationen.

Låt oss börja med att förklara varför konventionella commit-regler är bättre än icke-standardiserade commit-regler.

Om vi anställer nya utvecklare till ett projekt där de flesta åtaganden består av meddelanden i linje med att det borde fungera eller Sleepy fix för sidfot ASAP vad dyker upp i ditt huvud?

Jag skulle säga att röda flaggor eftersom:

• Vi vet inte exakt vad som ska fungera
• Varför tryckte någon på något när han var sömnig och potentiellt felaktig?
• Var lösningen förhastad om vi kan se ASAP-anteckningen?

Eftersom ditt team kan ha anpassade regler för när man överför ändringar finns det mindre utrymme för misstag eftersom din överföring måste vara solid. Det är inte längre ett sätt att bara checka ut. Det är en signatur som talar om för andra att du kände till innehållet i commiten. Jag behöver inte nämna att om det arbete du har gjort inte är korrekt signerat kommer det troligen att resultera i ett fel och du får ett meddelande

Det finns en chans att ditt team vill sätta upp en regel som inte tillåter vissa nyckelord så att ASAP eller svordomar kan finnas på den svarta listan.

Verktyg

Det som verkligen är bra i början av projektet är att introducera alla till hur din utvecklingsteam skulle vilja se nya utvecklare göra åtaganden för sina ändringar. Sätt sedan upp ett verktyg som hjälper dem att hålla jämna steg med vad ni alla kom överens om.

Ett av de verktyg som jag har haft möjlighet att arbeta med var commitlint och det gjorde konventionella commits till min metod när jag kommer till nya projekt som inte har några regler och där teamet är öppet för idén att införa dem.

När du hanterar inställningarna och sprider dem över ditt team kan du helt enkelt skapa ett npm-paket och bara mpn i -D det i varje projekt. Det kommer säkert att hjälpa alla i projektet att vara på samma sida hela tiden och om det behövs gå från projekt till projekt och förstå vad de senaste ändringarna handlade om (och varför de gjordes).

Vänner med flera fördelar

Så nu efter att ha ställt in allt och förstått varför det kan vara en bra idé att börja använda CC skulle den bästa delen vara att programmera runt de regler du just har tillämpat! Vi använder ett standardiserat sätt för hur vi begår, vi ägnar mer uppmärksamhet åt vad begåendet verkligen handlade om så varför inte ställa in krokar som gör att du snabbt kan testa på staging när en flagga är närvarande? Vi vill inte överbelasta tjänsterna och sänka kostnaderna när det behövs och det finns vissa skäl att testa på produktionsliknande server istället för localhost.

Låt oss anta att du arbetar med PWA och SSL behövs för att du ska kunna testa den fulla potentialen och att du har en SSL på din testplattform. Allt du behöver nu är bara en bra commit. Något i stil med feat(PWA): manifest icons workbox setup upload skulle utlösa hela maskineriet med testning och att flytta runt kugghjul. Vi behöver inte det när vi bara laddar upp några statiska data som manifest.json så vi lägger till en flagga [TEST_SKIP] som ett postfix till vår commit. Det gör det möjligt för vårt CI att bara ladda upp nya tillgångar till testmiljön och hoppa över testningen. Du kan läsa mer om det här

Efter ett tag kommer du att kunna se andra fördelar, till exempel att det blir lättare att generera CHANGELOG och bättre versionshantering med semantisk versionshantering. Om det inte räcker för att övertyga dig om att ändra ditt sätt att skriva meddelanden, kanske du kan ändra dig genom att doppa tårna i kallt vatten och försöka använda dem i ditt privata arkiv under en tid.

Trevlig konventionell pendling!

Uppdateringar av Ruby 3.0.0 av Ruby Community

En efterlängtad release av Ruby 3.0.0 har sett dagens ljus under julen så att alla Ruby-utvecklare där ute kan hitta den under julgranen när de vaknar på morgonen. På The Codest odlar vi kunskapsdelningskulturen genom att organisera veckovisa utvecklingsmöten där våra ingenjörer diskuterar tekniktrender och deras nya upptäckter som är värda uppmärksamheten. Nedan hittar du en länk till bilder från demodagen där vår senior Ruby-ingenjör diskuterade ett par viktiga förändringar i Ruby 3.0.0 ur hans subjektiva synvinkel:

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

Dessutom har vår Ruby-mentor bidragit till den nya versionen med sin pull request som framgångsrikt har sammanfogats. Mer om ämnet metoder för integritetskontroll hittar du nedan i den korta artikeln av vår utvecklingschef.

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

Tack så mycket för att du läste och om du har kommit så här långt uppskattar jag din tid och all feedback är mer än välkommen på LinkedIn eller till min e-post.

Kommer tillbaka till dig med nästa avsnitt i slutet av februari med granskningen av en podcast som intervjuar Shopifys CTO, mannen bakom ett ingenjörsteam som arbetar med den magnifika Ruby monolith-appen!

Vi ses.

Läs mer om detta:

TheCodestReview #4 - veckovis juice för mjukvaruutveckling

TheCodestReview #3 - veckovis juice för mjukvaruutveckling

TheCodestReview #2 - veckovis juice för mjukvaruutveckling