WordPress: Disabilitare i Google Fonts sul tema Jupiter X

Jupiter X è un tema per WordPress che concentra eleganza e personalizzabilità senza compromettere le performance del sito.

Tra le varie possibilità di personalizzazione del tema c’è non poteva mancare quella dei tipi di carattere da utilizzare. Tra i vari tipi di font che è possibile abilitare nel tema ci sono anche i Google Fonts.

Il problema con i Google Fonts però è che basta abilitarne una tipologia per fare in modo che il tema scarichi tutti i font di Google (compresi quelli non necessari). E il download di asset non necessari al sito non viene visto di buon occhio dall’indicatore delle performance dei segnali Web Vitals.

Sfortunatamente non esiste un modo per permettere il download selettivo dei font Google necessari (anche se gli sviluppatori ci stanno lavorando) ma esiste il modo per disattivare completamente il download dei Google Fonts e scaricare manualmente solo quelli utili.

Ma prima di vedere come disattivare completamente i Google Fonts mi presento: sono Lorenzo Millucci e sono un ingegnere del software che ama lavorare con Symfony e a cui piace condividere in questo blog le cose che impara. Non perderti anche il mio canale Telegram in cui ogni martedì parliamo di news e curiosità legate al mondo della tecnologia!

Disattivare completamente i Google Fonts

Per disattivare completamente i Google Fonts scaricati dal Jupiter X devi fare una piccola modifica al file functions.php:

function lm_disable_jupiterx_webfonts() {
    wp_dequeue_style( 'jupiterx-webfont' );
    wp_deregister_style( 'jupiterx-webfont' );
}
add_action( 'wp_print_styles', 'lm_disable_jupiterx_webfonts' ); 

Puoi fare questa modifica direttamente dal pannello di controllo del sito andando su Aspetto -> Editor del tema e selezionando la voce “Theme functions” oppure modificando il file wp-content/themes/jupiterx/functions.php con il tuo editor preferito.

Una volta salvate le modifiche il sito verrà caricato senza i Google Fonts. Se utilizzavi i Google Fonts in qualche pagina ora, avendoli disattivati, la vedrai con il font predefinito.

NOTA: Per accertarti che il cambiamento non lasci in cattivo stato qualche pagina ti consiglio di di fare un bel giro all’interno del sito verificando che non si sia rotto nulla.

Abilitare selettivamente i Google Fonts

Qualora tu abbia bisogno di attivare una singola font-family di font per il tuo sito puoi modificare lo script descritto precedentemente aggiungendo esplicitamente quale Google Font tu voglia caricare.

Ad esempio, se tu volessi caricare il font “Roboto” dovresti modificare lo script in questo modo:

function lm_disable_jupiterx_webfonts() {
    wp_dequeue_style( 'jupiterx-webfont' );
    wp_deregister_style( 'jupiterx-webfont' );
    
    // Import only webfonts actually used
    wp_enqueue_style( 'gfonts-roboto', 'https://fonts.googleapis.com/css2?family=Roboto:wght@100&display=swap' );
}
add_action( 'wp_print_styles', 'lm_disable_jupiterx_webfonts' ); 

Se questo post ti è stato utile puoi farmelo sapere lasciando un commento qui sotto oppure scrivendomi direttamente a t.me/lorenzomillucci.
Inoltre ti invito ad iscriverti al mio canale Telegram e a seguirmi su Twitter per non perderti nemmeno un post del mio blog. A presto!

Software engineer presso Slope.
Appassionato di videogame, nel tempo libero mi diletto a scrivere su questo blog.
Per non perderti nemmeno un post puoi seguirmi su Telegram!

Core Web Vitals: cosa sono a cosa servono e come si misurano

Ti sarà sicuramente capitato di navigare su di un sito inusabile a causa degli infiniti tempi di caricamento e della quantità smodata di banner di ogni sorta. Esperienza terribile.

Proprio l’esperienza di navigazione dell’utente sta per diventare uno dei fattori con cui Google deciderà l’ordinamento dei risultati del motore di ricerca.

Nella pagina about di Google si legge che lo scopo fondamentale del motore di ricerca è:

La nostra missione è organizzare le informazioni a livello mondiale e renderle universalmente accessibili e utili.

https://about.google

Organizzare le informazioni a livello mondiale significa trovare e catalogare tutte le pagine web esistenti in modo da fornire i migliori risultati possibili sulla base delle parole chiave digitate dall’utente.

Ma Google non si limita a classificare i risultati solamente in base al contenuto. Immagina di cercare una parola chiave come “miglior software gestionale per hotel” su Google.

Ti sei mai chiesto come faccia il motore di ricerca a decidere l’ordinamento con cui sono mostrati i risultati quando tutte le pagine hanno contenuti più o meno simili tra loro? Al fine di fornire anche in queste situazione i migliori risultati possibili, Google dichiara di tenere in considerazione oltre 100 fattori differenti!

E tra i fattori presi in considerazione, a partire dalla prima metà del 2021, uno che guadagnerà maggiore importanza nella definizione dell’ordinamento dei risultati di Google sarà proprio la così detta Page Experience. Proprio per misurare in maniera oggettiva la qualità di navigazione di un sito web Google aveva introdotto qualche anno fa i segnali Core Web Vitals. Nei prossimi mesi questi indicatori verranno inclusi all’interno del punteggio della Page Experience e da Maggio 2021 diventeranno un fattore di ranking a tutti gli effetti.

Questo vuol dire che a parità di contenuto un sito pulito, veloce a caricarsi e di facile consultazione verrà favorito rispetto ad un sito lento, pesante e complesso da usare.

NOTA: Chi si intende di ottimizzazione per i motori di ricerca conosce benissimo il motto “content is king” che sta a significare che il contenuto informativo il vero motivo per cui gli utenti aprono un sito. Questo motto continuerà ad essere valido anche con l’avvento dei Core Web Vitals tra i fattori di ranking. Un sito con il contenuto confuso e sgrammaticato ma con segnali Vitals al top continuerà ad essere penalizzato rispetto ad un sito con contenuto di qualità ma scarse performance.

Ma prima di trattare nel dettaglio dei Core Web Vitals mi presento: sono Lorenzo Millucci e sono un ingegnere del software che ama lavorare con Symfony e a cui piace condividere in questo blog le cose che impara. Non perderti anche il mio canale Telegram in cui ogni martedì parliamo di news e curiosità legate al mondo della tecnologia!


Indice


Cosa sono i segnali Core Web Vitals

I segnali Core Web Vitals sono degli indicatori che servono a rispondere alla domanda: “Qual’è l’esperienza di navigazione che il mio sito sta offrendo?”.

Secondo Google i concetti su cui si basa una navigazione di qualità sono tre:

  • Velocità: la navigazione deve avvenire senza la necessità di attendere tempi infiniti di caricamento tra una pagina e l’altra;
  • Interattività: una volta che il contenuto è stato mostrato a schermo l’utente non deve attendere un’infinità di tempo prima di poter interagire con la pagina;
  • Stabilità visuale: il contenuto della pagina non deve subire spostamenti mano a mano che i contenuti vengono caricati (es. viene caricato un banner pubblicitario che fa si che il testo venga scrollato più giù nella pagina).

Questi concetti possono essere misurati utilizzando rispettivamente le seguenti metriche:

  • Largest Contentful Paint (LCP): il caricamento dovrebbe avvenire entro 2.5s
  • First Input Delay (FID): dovrebbe essere possibile interagire con la pagina entro 100ms dal caricamento
  • Cumulative Layout Shift (CLS): il punteggio relativo alla stabilità non dovrebbe essere superiore a 0.1

I report di Google mostrano come un sito che soddisfi a pieno i requisiti di qualità appena definiti abbia un tasso di abbandono più basso del 24% rispetto ad uno sito che non li rispetta.

Misurare i Core Web Vitals

Ora che hai capito le motivazioni che hanno spinto Google ad introdurre i Core Web Vitals come indicatore dell’esperienza di navigazione percepita dall’utente vediamo come misurarli praticamente.

Una prima importante differenziazione da fare nella misura dei segnali Vitals è la distinzione tra “dati sul campo” e “dati sintetici”. I primi sono i dati raccolti da Google tramite l’analisi dei visitatori reali del sito web mentre i secondi sono dati ottenuti in laboratorio simulando quello che potrebbe essere il comportamento dell’utente nel sito.

Google (ovviamente) utilizza i dati sul campo per determinare l’ordinamento dei risultati di ricerca e ti farò vedere non sono facilmente accessibili. I dati sintetici invece possono essere generati facilmente e sono utilizzati principalmente dagli sviluppatori per individuare quali possono a cui gli utenti vanno incontro.

Google offre diversi strumenti per la misura dei Core Web Vitals che coprono diversi aspetti dello stesso problema e in particolare gli strumenti più usati sono:

  • Google Search Console
  • PageSpeed Insight
  • Lighthouse
I 3 strumenti più utilizzati per la misurazione dei segnali Core Web Vitals

Search Console

La Search Console è un servizio di Google dedicato ai webmaster con il quale è possibile monitorare e gestire la presenza del tuo sito nei risultati della ricerca Google.

Tra i vari report che è possibile consultare nella Search Console ne puoi trovare proprio uno dedicato interamente ai segnali Core Web Vitals.

Il report sui segnali web essenziali di Google Search Console

Il report della Search Console mostra i “dati sul campo” ed è ottimo per individuare rapidamente i problemi comuni a più pagine del sito visto che tutte le pagine con problematiche simili vengono raggruppate insieme. Ad esempio, se più pagine del sito hanno un layout comune con una grossa immagine in copertina, è molto probabile che il loro punteggio circa il Largest Contentful Paint (LCP) sia simile. In questi casi il report di Google segnalerà un eventuale problema su tutte le pagine.

Per farla breve la Google Search Console è lo strumento giusto da utilizzare per identificare eventuali problemi di performance a livello globale del sito. Lo svantaggio principale però della Console è che ogni punto del grafico è la media dei punteggi alle performance dei 28 giorni precedenti. Questo vuol dire che un miglioramento fatto oggi non sarà visibili nel report prima di un mese.

PageSpeed Insights (PSI)

PageSpeed Insight è un applicativo web di Google che permette di vedere nella stessa pagina sia i dati sul campo (se disponibili) che quelli sintetici. Tutto ciò che devi fare per ottenere il report di PageSpeed Insight è inserire l’URL della pagina da analizzare nell’applicazione e premere invio.

L’analisi del punteggio di questo blog da desktop secondo PageSpeed Insight

L’analisi svolta da questo strumento è relativa al singolo URL specificato e solo nel caso in cui la pagina sia frequentata da un numero sufficientemente alto di visitatori è possibile vedere i dati raccolti sul campo, altrimenti saranno mostrati solo dei dati sintetici raccolti tramite test automatici.

All’interno della pagina dei risultati dell’analisi sono presenti anche dei consigli relativi alle aree su cui concentrare l’attenzione per migliorare il punteggio della pagina. (Attenzione si tratta di suggerimenti ottenuti dal test sintetico eseguito sulla pagina, gli utenti reali potrebbero riscontrare problematiche differenti).

In breve, tramite l’analisi della PageSpeed Insight è possibile analizzare con precisione i dati reali delle performance misurate dai visualizzatori del sito per una determinata pagina.

L’obiettivo di questo strumento dovrebbe essere quello di mettere a confronto i dati reali con quelli sintetici così da vedere se c’è un’effettiva corrispondenza in modo da scongiurare l’ipotesi per cui i dati sintetici siano migliori di quelli effettivamente riscontrati dagli utenti.

Il problema principale di questo report è che se la pagina da analizzare non è sufficientemente trafficata otterrai solo i dati sintetici (misurati tramite Lighthouse).

Lighthouse

Lighthouse è uno strumento automatico di analisi dei siti web incluso all’interno di Chrome (o anche il nuovo Edge basato su Chromium).

Questo strumento è principalmente rivolto agli sviluppatori e ha come finalità la raccolta di dati sintetici sulle performance di un sito.

Lighthouse in particolare permette di ricavare vari report:

  • Performance del sito: è il report che contiene le metriche legate alle prestazioni (tra cui i Core Web Vitals) ed è in grado di fornire agli sviluppatori vari suggerimenti sulle aree in cui intervenire per migliorare l’esperienza dell’utente.
  • Progressive Web App: questo report è rilevante solo nel caso in cui abbinata al sito ci sia una PWA e serve ad identificare se il sito web aderisce a tutti gli standard richiesti ad una PWA.
  • Best Practices: questo report si concentra sugli aspetti legati alla sicurezza e sugli aspetti legati ai moderni standard di sviluppo web.
  • Accessibilità: questo report serve ad individuare eventuali problematiche che possano rendere la pagina web inutilizzabile da persone con disabilità.
  • SEO: in questo report è indicato quanto la pagina web è facile da scansionare per un motore di ricerca (non solo Google). Più il punteggio è alto e più sarà facile che la pagina venga indicizzata e compaia come risultato della ricerca di un utente.
Punteggio relativo alle performance misurato da Lighthouse su dev.to (in rosso ho evidenziato i Core Vitals)

La navigazione web in questi anni si sta spostando sempre più dai PC verso i dispositivi mobili come smartphone e tablet.

Google è ampiamente a conoscenza di questo fenomeno e proprio per questo motivo tiene in particolare considerazione questa categoria di dispositivi permettendo a Lighthouse di simulare l’esperienza utente da uno smartphone.

La navigazione da smartphone però non è sempre ottimale. Dispositivi dalla scarsa potenza di calcolo e connessioni lente e/o ballerine sono molto più comuni di quanto si pensi. Per tenere conto di queste situazionivo Lighthouse simula uno smartphone che non sia un top di gamma (Moto G4) e che sia sotto una connessione lenta (slow 4G = 1.6Mbps download / 750 Kbps upload – latenza 150ms).
Proprio a causa di questa scelta il sito web che si carica in un lampo nel tuo iPhone 12 Pro potrebbe ottenere un punteggio delle performance basso (per verificare questa ipotesi il test da eseguire è quello della PageSpeed Insight).

Il ragionamento che ha spinto Google ad percorrere questa strada è il seguente: se la pagina web ha performance buone su un dispositivo limitato sicuramente sarà un piacere consultarla su di un cellulare di ultima generazione.

Il modo più semplice per misurare i segnali Core Web Vitals tramite Lighthouse è utilizzarlo direttamente da Chrome usando i seguenti comandi:

  • Naviga sulla pagina per cui vuoi misurare le performance
  • Apri gli strumenti per sviluppatori usando F12 (o utilizzando ctrl+shift+I)
  • Seleziona dalle tab in alto il menù Lighthouse
  • Metti la spunta sulla voce “Performance” (e rimuovere le altre se non sei interessato agli altri report)
  • Seleziona mobile o desktop per decidere se quale report vuoi ottenere
  • Avvia il test tramite il bottone “Genera Report”

Al termine dell’analisi del sito verrà mostrato un voto complessivo del sito e sarà possibile analizzare nel dettaglio tutte le voci che concorrono alla determinazione del punteggio. Per sapere come sono combinate tra loro le voci per il calcolo del punteggio complessivo ti lascio la documentazione ufficiale di Google.

Nel momento in cui scrivo Lighthouse 6 utilizza questi pesi per mediare le metriche e determinare il punteggio complessivo

Il report è diviso in due sezioni: metrics e opportunities. I valori delle metriche sono quelli che vanno ad influire direttamente sul punteggio globale assegnato alle performance mentre le opportunità non incidono direttamente. In ogni caso aggiustare una delle problematiche segnalate nella sezione opportunità può avere un impatto sul valore di una delle metriche e quindi contribuire ad aumentare il punteggio globale.

Analizzando i le voci contenute nella sezione metriche è possibile individuare i valori dei Core Web Vitals:

  • Largest Contentful Paint
  • Cumulative Layout Shift
  • Total Blocking Time (che non è esattamente il First Input Delay ma lo approssima con buona precisione).

NOTA: se ti dovesse servire automatizzare la creazione del report per più pagine non perderti questo articolo.

Conclusione

L’ottimizzazione dei siti web per i motori di ricerca (SEO) non è una scienza esatta. Gli algoritmi usati dai motori di ricerca cambiano continuamente e quello che è valido oggi potrebbe non essere più valido domani. L’unica cosa certa è che ci sono dei principi generici a cui i motori di ricerca si ispirano costantemente. Tra questi principi fondamentali uno che nel 2021 acquisirà maggiore importanza sarà proprio la valutazione delle performance del sito misurata tramite i segnali Core Web Vitals.

Google ha avvisato con largo anticipo che il cambiamento avverrà intorno al mese di Maggio in modo da dare tempo a chiunque gestisca un sito di iniziare a valutarne le performance e ad apportare i cambiamenti necessari. Chi non si adegua in tempo vedrà soffiarsi il primo posto nei risultati di ricerca da i competitor.

Come ho accennato poco fa, Google non fornisce delle regole esatte ma solo dei principi a cui si ispira per questo motivo quello che è scritto in questo post potrebbe essere aggiustato e modificato da Google in ogni momento. Per tale motivo ho cercato di mettere sempre i link alla documentazione ufficiale in modo da poter risalire sempre alla fonte di ogni dato riportato nel post.


Se questo post ti è stato utile puoi farmelo sapere lasciando un commento qui sotto oppure scrivendomi direttamente a t.me/lorenzomillucci.
Inoltre ti invito ad iscriverti al mio canale Telegram e a seguirmi su Twitter per non perderti nemmeno un post del mio blog. A presto!

Software engineer presso Slope.
Appassionato di videogame, nel tempo libero mi diletto a scrivere su questo blog.
Per non perderti nemmeno un post puoi seguirmi su Telegram!

Responsible disclosure: SQL Injection su portale sanitario

Hero image: ho trovato una sql injection in un portale sanitario

I dati sanitari delle persone dovrebbero essere tra i segreti meglio custoditi al mondo visto che la loro divulgazione senza esplicito consenso risulterebbe in una gravissima violazione della privacy dei pazienti. Non a caso ogni singolo dato sanitario ottenuto può valere fino a 250$ nel mercato nero .

Proprio per questo motivo mi aspetto che gli applicativi software che trattano questi dati siano protetti seguendo i più alti standard di sicurezza informatica esistenti.

Immaginate il mio stupore quando mi sono accorto che uno dei portali web utilizzati dai medici per il controllo dei proprio assistiti era vulnerabile a quello che OWASP mette al primo posto come fattore di rischio per le web app: la SQL Injection.

Per chi non sapesse di che cosa parlo, tramite un attacco di tipo SQL Injection un attaccante è in grado di eseguire dei comandi in linguaggio SQL con i quali può leggere, alterare ed eliminare qualsiasi dato presente all’interno di un database.

Non oso nemmeno immaginare le conseguenze disastrose che avrebbe potuto avere l’accesso e la divulgazione non consentita dei dati anagrafici e dei percorsi sanitari di migliaia e migliaia di pazienti.

Ma prima di procedere con i dettagli della SQL Injection mi presento: sono Lorenzo Millucci e sono un ingegnere del software che ama lavorare con Symfony e a cui piace condividere in questo blog le cose che impara. Iscriviti anche al mio canale Telegram in cui ogni martedì parliamo di piccole curiosità legate al mondo della tecnologia!

Cos’è una SQL Injection

Un attacco di tipo SQL Injection è un attacco che sfrutta la mancata validazione degli input digitati dall’utente per fare in modo che questi vengano interpretati come comandi per il database al fine di introdursi in un sistema informatico.

SQL infatti è un linguaggio di programmazione utilizzato per creare, modificare ed interrogare un database relazionale.

Normalmente quando un utente prova ad inserire un’istruzione SQL all’interno di un campo di input (come potrebbe esserlo il campo username di una pagina di login) il sistema si occupa di validare i dati inseriti accertandosi che non ci siano caratteri illeciti e/o facendone la traslitterazione verso una versione non dannosa (ad esempio il carattere < di solito viene convertito in &lt;).

Se questo processo di validazione dei dati immessi dall’utente non avviene potrebbe essere possibile sferrare un attacco di tra quelli appartenenti alla famiglia delle injection (a cui la SQL Injection appartiene).

Il tipico esempio di SQL Injection riportato in tutti i libri di testo è quello di una schermata di login in cui, per verificare che username e password siano corretti, viene usata la seguente query:

SELECT * FROM users WHERE username = "Foo" AND password = "bar" 

Un attaccante potrebbe aggirare questa schermata di login digitando come username Foo e come password " OR "" = ". In questo modo la query con i dati inseriti dall’utente diventerebbe:

SELECT * FROM users WHERE username = "Foo" AND password = "" OR "" = "" 

E poiché l’uguaglianza tra stringhe vuote "" = "" risulta essere sempre verificata l’attaccante si vedrebbe garantito l’accesso al sistema come un regolare utente senza che sia stato necessario conoscerne la password.

La SQL Injection sul portale

Esattamente come nell’esempio descritto poco sopra, nel portale in questione era possibile aggirare la pagina di login confezionando una stringa SQL ad-hoc e usandola come nome utente.

Per verificare l’esistenza del problema mi è bastato inserire il carattere ' nel campo username della pagina di login ottenendo come risposta la query SQL che il server ha provato ad eseguire per verificare la correttezza delle credenziali inserite.

Il messaggio d’errore restituito inserendo il carattere ‘ come username

Una volta accertata l’esistenza del problema mi sono immediatamente preoccupato di contattare chi di dovere affinché approntasse un fix per la vulnerabilità.

Timeline

20/10/2020 Mi accorgo del problema sul portale

20/10/2020 Invio email all’indirizzo di supporto generico (mai risposta)

26/10/2020 Invio email al dirigente del reparto IT che mi mette in contatto con il tecnico incaricato del portale

28/10/2020 Riporto la vulnerabilità al tecnico responsabile

11/11/2020 Mi segnalano che la vulnerabilità è stata sistemata

Conclusioni

Il problema sembra essere stato corretto e ora quando si prova ad inserire il carattere ' all’interno dei campi di login non viene più visualizzata la query SQL eseguita ma viene mostrata una semplice pagina bianca. Tutto bene quel che finisce bene.

O no?

Sinceramente ho l’impressione che il problema sia stato “risolto” semplicemente nascondendo il messaggio d’errore e lasciando la vulnerabilità esattamente dove si trova ma siccome non sono in grado di dimostrare questa mia ipotesi confido nella bontà della correzione. Avrei dormito sogni tranquilli vedendo un messaggio d’errore generico del tipo “nome utente non valido” piuttosto che una pagina bianca.

In ogni caso, vista la natura estremamente sensibile dei dati sanitari, mi auguro che le istituzioni incaricate al controllo e alla gestione di questi dati si impegnino maggiormente a garantire i più alti standard di sicurezza possibili.


Se questo post ti è stato utile puoi farmelo sapere lasciando un commento qui sotto oppure scrivendomi direttamente a t.me/lorenzomillucci.
Inoltre ti invito ad iscriverti al mio canale Telegram e a seguirmi su Twitter per non perderti nemmeno un post del mio blog. A presto!

Software engineer presso Slope.
Appassionato di videogame, nel tempo libero mi diletto a scrivere su questo blog.
Per non perderti nemmeno un post puoi seguirmi su Telegram!

GitHub: Code Review direttamente da PHPStorm

Immagine di copertina: Code review da PHPStorm

Scrivere codice di qualità dovrebbe essere l’obiettivo primario di ogni sviluppatore che si rispetti. E, come scrivevo in un articolo sull’importanza della leggibilità del codice, far controllare il codice ad uno sviluppatore esterno prima del merge tramite le cosiddette “code review” è uno dei metodi più efficaci per garantire un codice di alta qualità.

GitHub, GitLab, Bitbucket… sono alcuni dei servizi più famosi che offrono un meccanismo di controllo del codice distribuito e che integrano la possibilità di svolgere le code review direttamente dal browser.

Nel 90% dei casi l’interfaccia offerte da queste piattaforme è più che sufficiente a fare una review ma non è così raro imbattersi in grossi cambiamenti che la UI non riesce a caricare tutti in un’unica volta.

Non sarebbe bello poter fare le code review direttamente da PHPStorm sfruttando tutte le potenzialità dell’IDE e soprattutto senza dover aprire il browser?

Bé, ho scoperto che si può!

Ma prima di mostrarti come fare mi presento: sono Lorenzo Millucci e sono un ingegnere del software che ama lavorare con Symfony e a cui piace condividere in questo blog le cose che impara. Ho anche un canale Telegram in cui ogni martedì condivido una mia riflessione su una notizia legata al mondo tecnologico!

Connettere PHPStorm a GitHub

La prima cosa da fare per poter visionare le Pull Requests aperte da PHPStorm è collegare il proprio IDE a GitHub. Per farlo basta andare su:

File > Settings > Version Control > GitHub

E premere il tasto + in alto a destra.

Ci verranno chieste le credenziali dell’account (e il codice di accesso nel caso in cui sia attiva la two-factor authentication).

Collegamento dell'account GitHub con PHPStorm
Collegamento dell’account GitHub con PHPStorm

Visualizzare le pull requests

Una volta completata la connessione con l’account per visualizzare le Pull Requests del progetto ti basta andare su:

VCS > Git > View Pull Requests
Visualizzare le pull requests aperte per il progetto

A questo l’IDE mostrerà l’elenco di tutte le Pull Request aperte nel repository del progetto. Selezionandone una sarà possibile visualizzare lo storico dei commit, l’elenco di tutti i cambiamenti e aggiungere nuovi commenti.

Di seguito trovi un paio di screenshot di come si mostra l’interfaccia dell’IDE quando si prova a fare una code review. (Ho preso come esempio la pull request #37595 di Symfony)

NOTA: io in questo articolo mi sono riferito a PHPStorm perché è l’IDE che utilizzo quotidianamente. La procedura descritta dovrebbe essere replicabile al 100% su qualunque altro prodotto della JetBrains (WebStorm, IntelliJ Idea, PyCharm ecc…)

Conclusioni

L’interfaccia web dei vari servizi di versioning del codice è molto buona e per diversi anni ho utilizzato solo quella per fare le code review ma da quando ho scoperto la possibilità di farle direttamente dall’IDE ho praticamente smesso di usarla. La possibilità di poter fare control+click per vedere la definizione di un metodo o la possibilità di utilizzare il potente motore di ricerca di PHPStorm sono delle comodità troppo grosse per poterle ignorare.

Sicuramente non sarà questa funzione a cambiarti la vita ma anche solo un 1% di miglioramento in una delle azioni che si svolgono frequentemente può portare a notevoli quantità di tempo risparmiato.


Se questo post ti è stato utile puoi farmelo sapere lasciando un commento qui sotto oppure scrivendomi direttamente a t.me/lorenzomillucci.
Inoltre ti invito ad iscriverti al mio canale Telegram e a seguirmi su Twitter per non perderti nemmeno un post del mio blog. A presto!

Software engineer presso Slope.
Appassionato di videogame, nel tempo libero mi diletto a scrivere su questo blog.
Per non perderti nemmeno un post puoi seguirmi su Telegram!

La leggibilità del codice

Codice illeggibile?

The rationale for the code being the primary source of documentation is that it is the only one that is sufficiently detailed and precise to act in that role [….].

This principle comes with a important consequence – that it’s important that programmers put in the effort to make sure that this code is clear and readable.

Martin Fowler – CodeAsDocumentation

Di solito gli sviluppatori non dedicano particolare attenzione alla scrittura della documentazione. Nel caso migliore è vista come un male necessario, nel caso peggiore invece è trattata come un task da fare il più tardi possibile (e tendenzialmente mai).

Recentemente, grazie alla diffusione di metodologie agili, la scrittura della documentazione sta diventando parte integrante del processo di sviluppo di un software. Infatti il processo di scrittura e di mantenimento della documentazione può essere semplificato inserendola all’interno del codice stesso. In questo modo il codice assume il ruolo di sorgente principale di documentazione di un progetto.

In questo articolo ti voglio parlare dell’importanza di mantenere una documentazione a scopo interno che sia ben fatta, con un codice che sia “parlante” e con il giusto numero di commenti. Per farlo cercherò di rispondere alle seguenti 3 domande:

  • Perché il codice deve essere leggibile?
  • Quando è che un codice è leggibile?
  • Come scrivo codice che sia leggibile?

Ma prima di rispondere a queste domande mi presento, sono Lorenzo Millucci e sono un ingegnere del software che ama lavorare con Symfony e a cui piace condividere in questo blog le cose che impara. Iscriviti al mio canale Telegram per non perderti nessuna notizia!

Perché il codice deve essere leggibile?

Affrontiamo subito l’elefante nella stanza: perché devo prendermi la bega di scrivere del codice che sia leggibile?

Lo sviluppo di software è un task che viene affrontato in team nella quasi totalità dei casi. Ormai quasi nessun progetto viene sviluppato da una singola persona. Questo vuol dire che il codice che oggi io scrivo da solo davanti al mio PC prima o poi dovrà essere letto e capito da altri sviluppatori in modo che possano modificarlo per correggere bug o per aggiungere nuova funzionalità.

Quando il codice non è facilmente leggibile, lo sviluppatore che dovrà modificare dopo di me quelle righe dovrà perdere una notevole quantità di tempo solo per capire cosa ho fatto e come l’ho fatto per quello che magari poteva essere un fix facile e veloce.

Nel caso peggiore il codice scritto potrebbe essere così astruso che uno sviluppatore, piuttosto che perdere tempo nel cercare di decifrarlo, potrebbe decidere di riscriverlo da capo. Ma il processo di riscrittura non è esente da rischi. Infatti non è raro che qualche edge-case particolare non venga coperto dal nuovo codice o che venga introdotto qualche bug che il codice originale non aveva. Tutto ciò rende quindi necessario iterare più e più volte il processo di scrittura aumentando notevolmente i tempi e i costi di sviluppo.

Un altro fenomeno che spesso si verifica quando il codice non è facilmente interpretabile dagli sviluppatori è quello chiamato “Shanghai programming”.
Hai presente il gioco Shanghai? Quello in cui c’è un mucchio di bastoncini e i giocatori si sfidano a chi ne sfila il numero maggiore senza muovere gli altri.
Bene, può accadere la stessa cosa nello sviluppo di un software. Uno sviluppatore, non riuscendo a capire cosa faccia il mio codice, potrebbe essere portato a cambiare solamente le parti strettamente necessarie ad implementare la funzionalità richiesta senza toccare il resto. Questo comportamento non può che portare ad un’ulteriore riduzione della leggibilità del codice.

Arrivati a questo punto non devi stupirti del fatto che il codice non leggibile sia uno dei più grandi contribuenti all’aumento incontrollato del debito tecnico.

Ora che hai capito il perché il codice deve essere facilmente leggibile da chiunque procediamo a chiarire quando è che un codice è leggibile (e di conseguenza quando non lo è).

Malore: La tipica reazione di uno sviluppatore di fronte ad un codice illeggibile
La tipica reazione di uno sviluppatore di fronte ad un codice illeggibile

Quando è che un codice è leggibile?

Sfortunatamente non esiste una risposta universale a questa domanda. A seconda del linguaggio utilizzato, del team o della singola persona presa in considerazione la risposta a questa domanda varia.

Quello che sicuramente possiamo dire è che un codice è illeggibile se non è formattato in modo coerente.
Ti è mai capitato di aprire un libro e vedere una pagina fitta-fitta di testo senza alcuna suddivisione in paragrafi? Quando succede a me la prima reazione è quella di chiudere il libro e lasciare perdere la lettura. Questa è la stessa reazione di uno sviluppatore che vede un codice mal-formattato.

Quindi una prima costatazione da fare è che per aumentare la leggibilità del codice è necessario stabilire delle convenzioni da seguire per l’impaginazione/formattazione del codice. Ad esempio definire che tutti i metodi devono essere scritti in camelCase. Oppure che l’indentazione del codice deve essere fatta utilizzando gli spazi piuttosto che tabulazioni, ecc…
Tipicamente per queste regole stilistiche ci vengono incontro vari tool automatici di analisi statica che, una volta definite le regole, evidenziano (e a volte correggono automaticamente) tutti gli errori che incontrano.

Ma è sufficiente definire delle regole stilistiche per scrivere del codice leggibile? Ovviamente la risposta è no.

Una volta che il codice è ben formattato bisogna iniziare a vedere che ciò che abbiamo scritto sia comprensibile anche agli altri membri del team di sviluppo.

La prima cosa da fare in questo caso è farsi una serie di domande:

  • Si riesce a seguire il flusso del codice?
  • Il nome di un metodo/variabile aiuta a capire a cosa serve?
  • E’ necessario aggiungere un commento ulteriore per chiarire cosa sto facendo?
  • ecc…

Una volta terminata questa fase di “auto-analisi” del codice posso finalmente affermare che il codice è chiaramente leggibile da me stesso.

Ma come dicevamo all’inizio orma si lavora sempre in team e quindi non è sufficiente che il codice che ho scritto sia leggibile da me ma deve essere leggibile da qualunque altro collega.

Ecco quindi la prova finale per garantire la leggibilità di un software: superare la code-review.

Solo nel caso in cui un altro sviluppatore sia effettivamente in grado di capire cosa fa il mio codice senza porre domande sul suo funzionamento e senza fraintenderne in alcun modo il flusso logico posso dire di aver prodotto un codice veramente leggibile.

Reazione di festeggiamento quando finalmente la code review passa
Finalmente il codice è leggibile

Come scrivo codice che sia leggibile?

Anche a questa domanda non esiste una risposta universalmente riconosciuta. Tuttavia alcuni principi da avere bene a mente durante lo sviluppo del software sono:

  • Single-responsibility principle (SRP): ogni elemento di un programma deve avere una e una sola responsabilità. In modo tale che per uno sviluppatore sia facile capire cosa andare a modificare in caso di necessità.
  • Don’t repeat yourself (DRY): ogni elemento di un programma deve essere scritto una e una sola volta all’interno della code-base. Deve esistere una sola fonte di verità in modo da garantire che la modifica di un blocco di codice non debba mai essere ripetuta in più volte in più punti dell’applicazione.
  • Naming significativo: i nomi degli attributi, delle funzioni e delle classi deve essere significativo ed essere pensato in modo tale da aiutare la comprensione del codice.
  • Commenti solo se necessari: con un buon naming si può fare a meno di molti blocchi di commenti. Tuttavia esistono porzioni di codice che richiedono ulteriori spiegazioni e che quindi devono essere necessariamente commentate. I buoni commenti spiegano il “perché” di una determinata scelta. Il “come” è spiegato dal codice.
  • Testing: sebbene i test automatici non migliorino direttamente la leggibilità di un blocco di codice, questi permettono di capire il contesto in cui il codice è utilizzato. Inoltre, anche con il codice più leggibile del mondo è facile incappare in errori. Solo con una suite di test automatici in grado di coprire tutto il software è possibile modificare un software senza il terrore di aver rotto qualcosa nel tentativo di aggiustare qualcos’altro.

Conclusioni

Spero che questo articolo ti abbia aiutato a capire “perché”, “quando” e “come” scrivere un codice leggibile. Sicuramente ha aiutato me a mettere in ordine varie idee e nozioni che avevo acquisito ma che non avevo mai avuto modo di organizzare in modo strutturato.

Come hai potuto leggere nel corso dell’articolo alla base di un codice leggibile non c’è nessun concetto astratto o complesso da capire. Si tratta di nozioni che chiunque abbia provato a programmare con un qualunque linguaggio conosce ma che di solito si tende a dimenticare in quanto concetti considerati banali.

Un ulteriore punto che ci tengo a precisare è che la perfezione non esiste. Esisterà sempre un modo più ricercato o più elegante per rendere maggiormente leggibile una porzione di codice.
Il problema è che poiché la leggibilità non è un concetto universalmente definito dagli sviluppatori si possono creare delle situazioni di stallo in cui opinioni differenti rischiano di bloccare completamente lo sviluppo. Proprio per evitare di cercare la perfezione a tutti i costi è fondamentale tenere a mente che molte volte è sufficiente che il codice sia leggibile da chi effettivamente dovrà lavorare sul codice. Ed è per questo che le code-review sono lo strumento principale per garantire la leggibilità del codice.

Infine c’è da dire che il codice non è scritto nella pietra. La ricerca della miglior leggibilità del codice è un processo continuo. Ogni volta che puoi migliorare la leggibilità è bene non indugiare e farlo subito in modo da ridurre il debito tecnico. Grazie alla suite di test automatici (che non a caso ho inserito tra i requisiti per un buon codice leggibile) potrai rifattorizzare il codice avendo la certezza di non aver rotto nulla.


Se questo post ti è stato utile puoi farmelo sapere lasciando un commento qui sotto oppure scrivendomi direttamente a t.me/lorenzomillucci.
Inoltre ti invito ad iscriverti al mio canale Telegram e a seguirmi su Twitter per non perderti nemmeno un post del mio blog. A presto!

Fonte
Fonte

Software engineer presso Slope.
Appassionato di videogame, nel tempo libero mi diletto a scrivere su questo blog.
Per non perderti nemmeno un post puoi seguirmi su Telegram!