Applicazioni e metodologie per sviluppare con Laravel

In questo breve articolo raccogliamo l’esperienza raccolta in questi anni di sviluppo per dare qualche suggerimento su applicativi e metodologie di lavoro per sviluppare con Laravel, che hanno migliorato la nostra qualità del lavoro nel tempo.

L’importanza del sistema operativo (e dell’hardware) per sviluppare con Laravel

Sappiamo che questo punto può facilmente diventare un enorme flame tra sostenitori (e detrattori) di questa o quella tecnologia ma in ComodoLab, fin dagli albori ci siamo affidati ad Apple. La stabilità del sistema operativo macOs unita alla flessibilità di un sistema basato su Unix ci hanno da sempre semplificato la vita.

È vero, le soluzioni professionali Apple non sono esattamente economiche ma per quanto ci riguarda le alternative, sul lungo periodo, sarebbero assolutamente più dispendiose in termini di tempo e frustrazione.

Per questo motivo alcuni degli strumenti che seguono sono specifici per macOs, mentre altri disponibili per tutte le piattaforme.

Gli strumenti per sviluppare con Laravel

Iniziamo dalla linea di comando.

• iTerm2. Seppure MacOs abbia un proprio terminale integrato noi optiamo per iTerm2 per le possibilità di personalizzazione. Più specificatamente tramite una configurazione ad-hoc possiamo utilizzare la modalità Quake mode e tramite uno shortcut personalizzato far comparire/scomparire il terminale dalla parte superiore dello schermo.
• Git. Il sistema di controllo di versione diventato lo standard de facto negli ultimi anni.
• Git flow. Applicazione di supporto all’omonimo flusso di lavoro. Semplificando, l’idea è di lavorare su una branch develop, sviluppando le nuove feature su branch dedicate e rilasciando la versione di produzione sulla main (o master).
• Oh My Zsh. Rimanendo in tema di terminale, Zsh è una shell alternativa a Bash… con i superpoteri. Oh My Zsh è un framework di configurazione costruito intorno a Zsh che promette: “Oh My Zsh will not make you a 10x developer…but you may feel like one!”. Tante funzionalità comodissime come l’auto-completamento dei comandi ed una migliore gestione dello storico, il tutto espandibile tramite un sistema di plugin. Valevole di nota il plugin zsh-artisan che ci faciliterà la vita quando lavoriamo con artisan.
• Starship. Un prompt per la shell specifico per sviluppatori. Quando all’interno della cartella di un progetto, avrete direttamente la versione dei vari linguaggi coinvolti (Node.js, Php, etc…) nonché tutte le informazioni sullo stato della branch corrente.
• Node.js. Indispensabile per fare minificazione, bundling e transpiling dei nostri asset Vue.js tramite Laravel Mix. Come bonus, JavaScript nella CLI si presta ottimamente a scrivere script per ottimizzare operazioni ripetitive.
• Composer. Gestore di dipendenze per PHP. Senza di esso (e senza tutti i pacchetti open source pubblicati su Packagist) oggi l’intero ecosistema del linguaggio PHP sarebbe molto, molto diverso.

L’ambiente di sviluppo locale.

Per poter sviluppare con Laravel in ambito LEMP/LAMP (Linux, Nginx, Apache, MySQL, PHP) adottiamo due diverse strategie in base alle necessità. Adottiamo Valet + DBNgin per replicare l’ambiente di sviluppo direttamente sulla macchina locale oppure usiamo Docker (e più specificatamente Laravel Sail) per ottenere ambienti più specifici, complessi ed isolati. Vediamo un pò tutti gli strumenti necessari.

• Docker. Necessario per il funzionamento di Laravel Sail, modalità di default con cui viene vengono installate le ultime versioni di Laravel.
• Laravel Valet. Un coltellino svizzero da linea di comando che permette di gestire la pubblicazione su Nginx e Dnsmasq di un host per ogni cartella mappata (con dominio nome-cartella.test), di variarne la versione di PHP e di attivarne i certificati locali.
• Phpmon (opzionale). Una semplice applicazione che si posiziona nella tray bar e ci permette di gestire alcune delle funzionalità di Laravel Valet tramite interfaccia grafica.
• DBngin. Con pochi click potrete lanciare un nuovo database PostgreSQL, MySQL o Redis.

Editor e client vari.

• PhpStorm. Per quanto ci riguarda l’IDE (Ambiente di sviluppo integrato) definitivo. Chiamarlo Editor di codice è infatti decisamente riduttivo. In un solo strumento abbiamo analisi, correzione e auto-completamento del codice, integrazione con i sistemi di versioning e di testing, client per database, client FTP e strumenti vari per il rilascio. E’ vero che non si dovrebbe imputare la qualità di uno sviluppatore agli strumenti che usa eppure non possiamo puntualizzare abbastanza quanto questo strumento ci abbia reso sviluppatori migliori.
• TablePlus. Se il client integrato in PhpStorm non fosse sufficiente, assieme a DBngin viene installato questo software freemium (la versione gratuita ha alcune limitazioni) fatto davvero benissimo. Curato esteticamente, shortcut da tastiera intuitivi e tante accortezze che rendono (quasi) un divertimento lavorare sui database.
• Sublime Text (o Visual Studio Code). Ma non avevamo appena detto come PhpStorm fosse l’IDE definitivo? Si ma se vogliamo trovargli un difetto è sicuramente quello della reattività e della gestione di file di grandi dimensioni (soprattutto su hardware un pó datato). Quando abbiamo bisogno di gestire file di log o modificare velocemente un file, Sublime Text o Visual Studio Code sono a nostro avviso più adeguati. Parlando di velocità pura con Sublime Text davanti a tutti gli altri.

All’interno del progetto.

La maggior parte degli strumenti sopra elencati per sviluppare con Laravel, vengono installati sulla macchina di sviluppo. Ce ne sono alcuni che invece vengono installati all’interno del singolo progetto tramite le dipendenze di sviluppo specificate all’interno dei file composer.json.

• PhpUnit. Avendo iniziato la mia carriera come sviluppatore WordPress, il mio primo approccio al testing automatizzato tramite PhpUnit è stato un pò come avere l’occasione di mettere le mani su un motore Ferrari per un meccanico Fiat. Lo stupore iniziale è stato poi rimpiazzato dalla fede (quasi) cieca nel poter ri-fattorizzare in qualsiasi momento i nostri progetti senza dover temere il peggio.
• PhpStan. L’analisi statica dei tipi è diventato un modo essenziale per scoprire errori nel codice prima ancora di averlo eseguito.
• PHP CS Fixer. Mano a mano che il team si è allargato (e con il lavoro remoto) è diventato sempre più importante adottare uno stile unico e condiviso nella scrittura del codice. Tra le altre cose, tramite PHP CS Fixer, siamo certi che i nostri commit contengano solo modifiche rilevanti e non variazioni sporadiche delle spaziature o di altri elementi stilistici.
• Infection PHP. Purtroppo questo è uno strumento con cui non abbiamo ancora avuto modo di prendere confidenza. L’idea di base è di introdurre variazioni casuali all’interno del nostro codice e verificare se i relativi test falliscano. Un ottimo modo per verificare la qualità delle proprie test suites.
• Rector. Uno strumento ottimo per il refactoring automatizzato del codice. Ancora non l’abbiamo inserito nella nostra CI ma già usato in più di un’occasione per aggiornare la versione PHP supportata dei nostri progetti.
• Laravel Debugbar. Ottima per fare il debug delle query al database, della cache e delle altre integrazioni del framework.
• XDebug. Ad essere completamente onesti lo usiamo poco e solitamente solo in quei casi in cui ci sia un leak di memoria o comportamenti talmente strani da non poterne fare il debug tramite semplice dump and die.

Collaborazione.

Come strumenti per collaborare su progetti Laravel utilizziamo principalmente GitHub e nello specifico:

• Issues. Raccogliamo tutte le segnalazioni di bug o richieste di nuove implementazioni sulle Issues di GitHub. In tal modo possiamo discutere le varie implementazioni prima ancora di implementarle e poi gestirne priorità ed assegnazione tramite GitHub Projects (attualmente in beta).
• Pull Requests. Facendo passare ogni nuova feature o bug fix tramite PR riusciamo a gestire al meglio sia la sua discussione che la sua integrazione sulla branch di sviluppo. Ad ogni commit su una PR o al suo merge corrisponde l’esecuzione della nostra CI che ci assicura che test, verifica degli stili e analisi statica passino prima di procedere con la messa in produzione.
• Code Reviews. L’uso delle PR si porta dietro la possibilità di far revisionare il proprio lavoro ai colleghi prima di integrarlo con il resto del codice.
• Changelog. Referenziamo tutte le modifiche effettuate su un file changelog.md che committiamo sulla repository, utilizzando gli hash delle relative Issues e PR in modo che chiunque possa accedere allo storico e comprendere il ragionamento dietro alle varie implementazioni.

Continuos integration e Deployment.

Al bando i client FTP in favore del deployment continuo del nostro codice grazie alle GitHub Actions. Al merge della branch di sviluppo sulla main (o master) parte automaticamente la nostra suite di test, se la suite passa facciamo il build degli asset (JS e CSS) e poi richiamiamo uno script sul server di produzione (o di staging) che si occupa di mettere l’applicazione in manutenzione, fare il deploy del codice, effettuare le migrazioni, pulire la cache e rimettere il tutto online in pochi secondi.

In produzione.

Come strumenti di monitoraggio sulle applicazioni in produzione utilizziamo principalmente:

• BugSnag. Per raccogliere i log di errori che riguardano sia frontend e che backend.
• Laravel Horizon. Per gestire e monitorare le code.

Per concludere

Chiaramente quanto premesso rappresenta una linea generale per sviluppare con Laravel. All’interno del nostro stesso team i vari membri che sviluppano applicazioni Laravel utilizzano configurazioni che si discostano in parte da quanto suggerito in base a preferenze personali e tecnologie adottate.

Infine, per poter far stare tutto in un singolo articolo di blog abbiamo dovuto banalizzare temi importanti come il testing o l’analisi statica. Speriamo che ne possa emergere qualche input positivo, soprattutto per quegli sviluppatori junior che si trovino in difficoltà nell’enorme possibilità di scelta insito nel nostro lavoro.

Buona programmazione!