KEREN TERUG
Deze aflevering stond gepland voor publicatie in december voor de kerstvakantie, dus het lijkt erop dat ik de bottleneck ben die verantwoordelijk is voor de vertraging. Ik heb de publicatie week na week uitgesteld omdat een paar taken met een hoge prioriteit in de weg stonden, maar vandaag is DE dag.
In de vorige aflevering heb ik geplaagd om commentaar te geven op het artikel over het belang van humor op de werkplek, maar ondertussen ben ik erachter gekomen dat het veel meer eer verdient, dus ik ga er binnenkort een hele blogpost over schrijven.
Dingen die me de afgelopen weken bezig hebben gehouden:
a) Voor Kerstmis begon ik met de eerste aflevering van "Kogelvrije CTO" webinarserie (blijf kijken voor 2e aflevering in februari met SaaS CTOsDetails volgen binnenkort op mijn LinkedIn).
b) Het afstemmen van ons groeiplan voor 2021 met als doel verder te gaan dan onze Ruby en JS core business en een Magento en Product Ontwerpcompetentie intern.
Genoeg zelfpromotie, laat me je uitnodigen voor de 5e aflevering van onze #TheCodestReview serie.
Onderwerpen team heeft voorbereid voor deze tijd:
Het commentaar op de frontend applicatie en conventionele commits worden deze week geleverd door onze React engineers, terwijl Ruby 3.0.0 door ons Ruby dream team wordt geleverd.
Tegenwoordig gebruiken veel ontwikkelaars om tijd te besparen reeds gemaakte UI-bibliotheken en herbruikbare componenten. Dat is een goede gewoonte en het helpt ons veel tijd te besparen, maar wanneer onze project groter wordt - zul je begrijpen dat het niet genoeg is om met code.
Er zijn twee goede patronen uit de back-end ontwikkeling - Domain Driven Development (DDD) en Separation of Concerns (SoC). We kunnen ze ook gebruiken in front-end architectuur.
In DDD proberen we gelijksoortige functies te groeperen en zoveel mogelijk los te koppelen van andere groepen (modules).
Terwijl we bij SoC bijvoorbeeld logica, views en datamodellen scheiden (bijvoorbeeld met behulp van het MVC- of MVVM-ontwerppatroon).
Er zijn veel goede praktijken en patronen om te gebruiken, maar deze manier heeft voor mij de voorkeur.
Als we dit patroon gebruiken, krijgen we dit beeld:
Aan het begin wordt de gebruiker naar de juiste module geleid door de routing van de app. Elke module is volledig op zichzelf staand. Maar omdat een gebruiker verwacht één applicatie te gebruiken, en niet een paar kleine, zal er enige koppeling bestaan. Deze koppeling bestaat op specifieke functies of bedrijfslogica.
En we hebben deze structuur:
app map - toepassingslaag
assets - map voor afbeeldingen, lettertypen, pictogrammen enz.
componenten - hier moeten componenten voor hergebruik zijn die geen ingewikkelde logica hebben
config - hier slaan we de globale status op
lib - map voor ingewikkelde functies en het berekenen van logica
modules - hier zijn onze modules
pubsub - plaats voor het opslaan van schema's voor het beschrijven van gegevensstructuren.
styles - voor onze css/scss-code
Deze structuur zal ons helpen om met onze groeiende applicatie om te gaan en minder bugs te hebben. Het zal ook helpen om comfortabeler te werken met afzonderlijke modules, om ze te testen en om refactoring en debugging gemakkelijker te maken (door afzonderlijke modules).
Als we dieper kijken naar de architectuur van modules en hun verbindingen met API's, krijgen we zoiets:
In de map 'app' maken we een andere map 'api' met code voor API-aanroepen en gegevens slaan we op in 'config/store'. Hier bewaren we statische en onveranderlijke gegevens die we in de hele applicatie gebruiken.
Ook in de map 'pubsub/schema' beschrijven we specifieke gegevenstypen voor JavaScript objecten.
Alle modules bevatten gegevens die we moeten gebruiken (gebruikers, routes, tabellen, acties enz.). Elke module is verbonden met de applicatielaag en neemt alle benodigde gegevens op.
De front-end is de eerste ingang voor onze gebruikers. Omdat onze front-end projecten steeds meer mogelijkheden krijgen, zullen we ook meer bugs introduceren. Maar onze gebruikers verwachten geen bugs en snel nieuwe functies. Dit is onmogelijk. Maar door een goede architectuur te gebruiken kunnen we alleen maar proberen om dit zoveel mogelijk te bereiken.
Stel je voor dat je aan het begin staat van een bedrijf waar je net bent aangenomen. Alle mensen zijn aardig tegen je en alles lijkt prima tot het moment dat je wordt geïntroduceerd in een codebase van voordat JavaScript een taal was en Netscape een pagina laadde voor wat een eeuwigheid lijkt.
De overerving van code lijkt een enorm probleem te zijn bij het introduceren van nieuwe ontwikkelaars in een project. De code lezen is één ding, maar begrijpen hoe de applicatie ontwikkeld is, is niet helemaal hetzelfde. Vaak blijken commits nuttig te zijn en context te geven waarom deze console.logs niet gevangen werden door linter of waarom die vervelende // TODO er is voor kinderen van de ontwikkelaar die in eerste instantie de annotatie maakte.
Laten we beginnen met waarom conventionele commits beter zijn dan niet-gestandaardiseerde commit regels.
Als we nieuwe ontwikkelaars aannemen voor een project waarin de meeste commits bestaan uit berichten in de trant van dat zou moeten werken of Sleepy fix voor footer ASAP wat komt er dan in je op?
Ik zou zeggen dat rode vlaggen omdat:
Omdat je team aangepaste regels kan laten toepassen op wanneer iemand veranderingen committeert, is er minder ruimte voor fouten omdat je commit solide moet zijn. Het is niet langer een manier om gewoon uit te checken. Het is een handtekening die andere mensen vertelt dat je de inhoud van de commit kende. Het is niet nodig om te vermelden dat als het werk dat je gedaan hebt niet correct ondertekend is, het hoogstwaarschijnlijk zal resulteren in een fout en je een melding zal geven
De kans bestaat dat je team een regel wil instellen die bepaalde trefwoorden verbiedt, zodat ASAP of scheldwoorden op de zwarte lijst komen te staan.
Wat echt helpt aan het begin van het project is om iedereen te laten zien hoe je ontwikkelteam zou graag zien dat nieuwe ontwikkelaars hun wijzigingen vastleggen. Zet dan een tool op die hen helpt bij te houden wat jullie allemaal hebben afgesproken.
Een van de tools waarmee ik heb kunnen werken was commitlint en het maakte conventionele commits mijn go-to praktijk wanneer ik bij nieuwe projecten kom die geen regels hebben en het team open staat voor het idee om ze te introduceren.
Als je met de instellingen omgaat en ze over je team verspreidt, kun je gewoon een npm-pakket maken en het gewoon in elk project uploaden. Dat zal zeker iedereen in het project helpen om altijd op dezelfde pagina te zitten en indien nodig van project naar project te lopen en te begrijpen wat de laatste wijzigingen waren (en waarom ze werden gemaakt).
Dus nu nadat je het allemaal hebt ingesteld en begrijpt waarom het een goed idee zou kunnen zijn om CC te gaan gebruiken, zou het beste gedeelte zijn om te programmeren rondom de regels die je zojuist hebt toegepast! We gebruiken een gestandaardiseerde manier van hoe we committen, we besteden meer aandacht aan waar de commit echt over ging, dus waarom geen hooks instellen die je toestaan om snel te testen op staging wanneer er een vlag aanwezig is? We willen diensten niet overbelasten en snijden in de kosten wanneer dat nodig is en er zijn enkele redenen om te testen op een productie-achtige server in plaats van localhost.
Laten we aannemen dat je aan PWA werkt en SSL nodig hebt om het volledige potentieel te testen en dat je een SSL hebt op je testplatform. Alles wat je nu nodig hebt is een goede commit. Iets in de trant van feat(PWA): manifest icons workbox setup upload zou de hele machinerie van testen en tandwielen verplaatsen in gang zetten. We hebben dat niet nodig als we alleen wat statische data zoals manifest.json uploaden, dus voegen we een vlag [TEST_SKIP] toe als een postfix aan onze commit. Dat stelt onze CI in staat om gewoon nieuwe assets te uploaden naar de testomgeving en het testen over te slaan. Je kunt daar meer over lezen hier
Na een tijdje zul je andere voordelen zien, zoals het gemak van het genereren van CHANGELOG en beter versiebeheer met semantisch versiebeheer. Als dat niet genoeg is om je te overtuigen om je manier van het schrijven van vastleggingsberichten te veranderen, dan zou het misschien je gedachten kunnen veranderen als je je tenen eens in fris, koud water doopt en ze een tijdje in je privé-repository probeert te gebruiken.
Gelukkig conventioneel plegen!
Een langverwachte in de gemeenschap Ruby 3.0.0 release heeft het daglicht gezien met Kerstmis, zodat alle Ruby ontwikkelaars die er zijn het kunnen vinden onder de kerstboom zodra ze wakker worden in de ochtend. Bij The Codest cultiveren we de cultuur van het delen van kennis door het organiseren van wekelijkse dev vergaderingen waar onze ingenieurs discussiëren over technologische trends en hun nieuwe ontdekkingen die de aandacht waard zijn. Hieronder vind je een link naar slides van de demodag waar onze senior Ruby engineer een aantal belangrijke veranderingen in Ruby 3.0.0 vanuit zijn subjectieve oogpunt besprak:
https://drive.google.com/file/d/1rboAusV1UTWXYMVGuLHx6O90lXrgkmnO/view?usp=sharing
Verder heeft onze Ruby mentor bijgedragen aan de nieuwe versie met zijn pull request dat succesvol is samengevoegd. Meer over het onderwerp privacycontrolemethoden vindt u hieronder in het korte artikel van ons hoofd ontwikkeling.
https://thecodest.co/blog/ruby-3-0-ruby-and-lesser-known-privacy-control-methods
Bedankt voor het lezen en als je zover bent gekomen, waardeer ik je tijd en alle feedback is meer dan welkom op LinkedIn of in mijn e-mail.
Eind februari is de volgende aflevering met een bespreking van een podcast met Shopify's CTO, de man achter een engineering team dat werkt aan de prachtige Ruby monolith app!
Tot ziens.
Lees meer:
TheCodestReview #4 - wekelijks software engineering sap
Dutch 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Polish 
Arabic 
Italian 
Japanese 
Korean 
Spanish 
Estonian 
Greek