TORNA INDIETRO
La pubblicazione di questo episodio era prevista per dicembre, prima delle vacanze di Natale, quindi sembra che sia io il collo di bottiglia da incolpare per il ritardo. Ho continuato a ritardare la pubblicazione di settimana in settimana perché alcune attività ad alta priorità si sono intromesse, ma oggi è il giorno giusto.
Nell'ultima puntata ho stuzzicato l'idea di commentare l'articolo sull'importanza dell'umorismo sul posto di lavoro, ma nel frattempo ho capito che merita molto più credito, quindi presto scriverò un intero post sul blog a riguardo.
Le cose che mi hanno tenuto occupato nelle ultime due settimane:
a) Prima di Natale ho iniziato con la prima puntata di "Serie di webinar "A prova di proiettile CTO (rimanete sintonizzati per il secondo episodio di febbraio con SaaS CTOs, i cui dettagli seguiranno a breve sul mio LinkedIn).
b) Mettere a punto il nostro piano di crescita per il 2021 con l'obiettivo di andare oltre il nostro core business di Ruby e JS e di far crescere un'attività di Magento e di Prodotto Competenza nel design in casa.
Basta con l'autopromozione, lasciate che vi inviti al quinto episodio della nostra serie #TheCodestReview.
Argomenti il mio squadra ha preparato per questo momento:
I commenti sull'applicazione frontend e i commit convenzionali vengono consegnati questa settimana dai nostri ingegneri React mentre Ruby 3.0.0 dal nostro Ruby dream team.
Oggi molti sviluppatori, per risparmiare tempo, utilizzano librerie UI e componenti riutilizzabili già pronti. È una buona pratica e ci aiuta a risparmiare molto tempo, ma quando le nostre progetto diventa più grande - capirete che non è sufficiente gestire con codice.
Esistono due buoni modelli di sviluppo back-end: Domain Driven Development (DDD) e Separation of Concerns (SoC). Possiamo usarli anche nell'architettura front-end.
In DDD cerchiamo di raggruppare caratteristiche simili e di disaccoppiarle il più possibile da altri gruppi (moduli).
Mentre con i SoC, ad esempio, separiamo la logica, le viste e i modelli di dati (ad esempio, utilizzando il modello di progettazione MVC o MVVM).
Ci sono molte buone pratiche e modelli da utilizzare, ma per me questo modo è il preferito.
Se utilizziamo questo schema, otterremo questa immagine:
All'inizio l'utente viene reindirizzato al modulo corretto dal routing dell'app. Ogni modulo è completamente contenuto. Tuttavia, poiché l'utente si aspetta di utilizzare un'unica applicazione e non alcune piccole applicazioni, esiste un certo accoppiamento. Questo accoppiamento riguarda specifiche funzionalità o logiche di business.
E abbiamo questa struttura:
cartella app - livello applicazione
assets - cartella per immagini, font, icone ecc.
componenti - qui dovrebbero esserci componenti da riutilizzare che non hanno una logica complicata
config - qui si memorizza lo stato globale
lib - cartella per funzioni complicate e logica di calcolo
moduli - ecco i nostri moduli
pubsub - luogo di memorizzazione degli schemi per la descrizione della struttura dei dati.
stili - per il nostro codice css/scss
Questa struttura ci aiuterà a gestire la nostra applicazione in crescita e ad avere meno bug. Inoltre, ci aiuterà a lavorare più comodamente con moduli separati, a testarli e a facilitare il refactoring e il debugging (grazie ai moduli separati).
Se approfondiamo l'architettura dei moduli e le loro connessioni con le API, otterremo qualcosa di simile:
Nella cartella 'app' creeremo un'altra cartella 'api' con il codice per le chiamate API e i dati che salveremo in 'config/store'. Qui conserviamo i dati statici e immutabili che utilizzeremo nell'intera applicazione.
Anche nella cartella 'pubsub/schema' verranno descritti tipi di dati specifici per JavaScript oggetti.
Tutti i moduli contengono dati che dobbiamo utilizzare (utenti, rotte, tabelle, azioni, ecc.). Ogni modulo è collegato al livello applicativo e prende tutti i dati necessari.
Il front-end è il primo punto di accesso per i nostri utenti. Con l'aumento delle funzionalità dei nostri progetti front-end, introdurremo anche più bug. Ma i nostri utenti si aspettano che non ci siano bug e che le nuove funzionalità siano veloci. Questo è impossibile. Tuttavia, utilizzando una buona architettura possiamo solo cercare di raggiungere questo obiettivo il più possibile.
Immaginate di essere al punto di partenza in un'azienda in cui siete appena stati assunti. Tutte le persone sono gentili con voi e tutto sembra andare bene fino al momento in cui vi viene presentata una base di codice che risale a prima che l'JavaScript fosse un linguaggio e che Netscape caricasse una pagina per un tempo che sembra infinito.
L'ereditarietà del codice sembra essere un problema enorme quando si introducono nuovi sviluppatori in un progetto. Leggere il codice è una cosa, ma capire come è stata sviluppata l'applicazione non è la stessa cosa. Spesso i commit si rivelano utili e forniscono un contesto per capire perché questi console.log non sono stati catturati da linter o perché quel brutto // TODO è lì per i figli dello sviluppatore che ha fatto inizialmente l'annotazione.
Cominciamo col dire perché i commit convenzionali sono migliori delle regole di commit non standardizzate.
Se assumiamo nuovi sviluppatori per un progetto in cui la maggior parte dei commit consiste in messaggi del tipo "dovrebbe funzionare" o "Sleepy fix for footer ASAP", cosa vi viene in mente?
Direi che le bandiere rosse perché:
Poiché il team può avere regole personalizzate applicate al momento del commit delle modifiche, c'è meno spazio per gli errori quando il commit deve essere solido. Non è più un modo per fare il check-out. È una firma che indica agli altri che si conosce il contenuto del commit. Non c'è bisogno di dire che se il lavoro svolto non è stato firmato correttamente, molto probabilmente si otterrà un errore e verrà visualizzato un messaggio
È possibile che il vostro team voglia impostare una regola che escluda determinate parole chiave, per cui ASAP o qualsiasi parolaccia possono essere inserite nella lista nera.
All'inizio del progetto è utile presentare a tutti il modo in cui il progetto è stato concepito. team di sviluppo vorrebbe che i nuovi sviluppatori impegnassero le loro modifiche. Quindi create uno strumento che li aiuti a tenere il passo con ciò che avete concordato.
Uno degli strumenti con cui ho avuto la possibilità di lavorare è stato commitlint e ha fatto sì che i commit convenzionali diventassero la mia pratica preferita quando si tratta di nuovi progetti che non hanno regole e il team è aperto all'idea di introdurle.
Quando si ha a che fare con le impostazioni e le si diffonde all'interno del team, si può semplicemente creare un pacchetto npm e inserirlo in ogni progetto con un semplice mpn i -D. Questo aiuterà sicuramente tutti i membri del progetto a essere sempre sulla stessa lunghezza d'onda e, se necessario, a passare da un progetto all'altro comprendendo quali sono state le ultime modifiche (e perché sono state fatte).
Quindi, dopo aver configurato il tutto e aver capito perché potrebbe essere una buona idea iniziare a usare CC, la parte migliore sarebbe programmare intorno alle regole appena applicate! Stiamo usando un modo standardizzato di fare commit, prestiamo più attenzione a ciò che il commit riguarda realmente, quindi perché non impostare degli hook che permettano di fare dei test rapidi sullo staging quando è presente un flag? Non vogliamo sovraccaricare i servizi e tagliare i costi quando necessario e ci sono alcune ragioni per testare su un server di produzione invece che su localhost.
Supponiamo che stiate lavorando su una PWA e che l'SSL sia necessario per testarne tutte le potenzialità e che abbiate un SSL sulla vostra piattaforma di test. Tutto ciò che serve ora è solo un buon commit. Qualcosa di simile a feat(PWA): manifest icons workbox setup upload attiverebbe l'intero meccanismo di test e di spostamento delle ruote dentate. Non ne abbiamo bisogno quando carichiamo solo dati statici come manifest.json, quindi aggiungiamo un flag [TEST_SKIP] come postfix al nostro commit. Questo permette al nostro CI di caricare solo le nuove risorse nell'ambiente di test e di saltare i test. Per saperne di più qui
Dopo un po' di tempo si potranno notare altri vantaggi, come la facilità di generare CHANGELOG e una migliore gestione delle versioni con versionamento semantico. Se questo non basta a convincervi a cambiare il vostro modo di scrivere i messaggi di commit, forse immergere le dita dei piedi nell'acqua fresca e provare a usarle nel vostro repository privato per un po' vi farà cambiare idea.
Buon impegno convenzionale!
La tanto attesa release Ruby 3.0.0 della comunità ha visto la luce a Natale, in modo che tutti gli sviluppatori Ruby là fuori potessero trovarla sotto l'albero di Natale una volta svegliati al mattino. In The Codest coltiviamo la cultura della condivisione delle conoscenze organizzando riunioni settimanali di sviluppo in cui i nostri ingegneri discutono delle tendenze tecnologiche e delle loro nuove scoperte degne di attenzione. Qui di seguito potete trovare un link alle diapositive della giornata dimostrativa in cui il nostro ingegnere senior Ruby ha discusso un paio di importanti cambiamenti in Ruby 3.0.0 dal suo punto di vista soggettivo:
https://drive.google.com/file/d/1rboAusV1UTWXYMVGuLHx6O90lXrgkmnO/view?usp=sharing
Inoltre, il nostro mentore Ruby ha contribuito alla nuova versione con una richiesta di pull che è stata accorpata con successo. Per saperne di più sul tema dei metodi di controllo della privacy, potete consultare il breve articolo del nostro responsabile dello sviluppo.
https://thecodest.co/blog/ruby-3-0-ruby-and-lesser-known-privacy-control-methods
Grazie mille per aver letto e se siete arrivati fin qui, vi ringrazio per il tempo che mi avete dedicato e ogni feedback è più che benvenuto su LinkedIn o alla mia e-mail.
Il prossimo episodio, a fine febbraio, con la recensione di un podcast che intervista CTO di Shopify, l'uomo che sta dietro a un team di ingegneri che lavora alla magnifica app monolite in Ruby!
Ci vediamo in giro.
Per saperne di più:
TheCodestReview #4 - succo settimanale di ingegneria del software
TheCodestReview #3 - succo settimanale di ingegneria del software
TheCodestReview #2 - succo settimanale di ingegneria del software
Italian 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Arabic 
Japanese 
Korean 
Polish