CSS Audit: Valutare Attentamente il Codice

Benefici di una verifica#section1

Una verifica, o audit, vi aiuta ad organizzare il vostro codice e ad eliminare le ripetizioni. Non scrivete codice durante un audit: fate semplicemente l’inventario di quello che c’è e documentate le raccomandazioni da passare al cliente o da discutere con il vostro team. Queste raccomandazioni assicurano che nel nuovo codice non si ripeteranno gli errori passati. Diamo un’occhiata più da vicino agli altri benefici:

• Riduce la dimensione dei files. Una visione di insieme del CSS vi lascia il tempo di trovare dei modi per fare il refactoring del codice: pulirlo e magari tagliare il numero di proprietà. Potete anche cercare cose varie come versioni datate di prefissi per i browser che non vengono più usati. Eliminare il codice inutilizzato e non necessario taglia la dimensione del file che le persone devono scaricare quando visitano il vostro sito.
• Assicura la consistenza con le linee guida. Mentre fate l’audit, create la documentazione riguardante i vostri stili e cosa succede con il sito o l’applicazione. Potreste fare una style guide formale o semplicemente scrivere delle raccomandazioni per far notare come vengono usati pezzi diversi del vostro codice. Qualunque forma assuma la vostra documentazione, farà risparmiare molto tempo e problemi a chiunque entrerà nel vostro team, perché potranno familiarizzare facilmente con il CSS e l’architettura del vostro sito.
• Standardizza il vostro codice. L’organizzazione del codice, che sicuramente attrae diverse opinioni, è essenziale per far sì che la vostra codebase sia più facile da mantenere nel futuro. Ad esempio, se scegliete di mettere in ordine alfabetico le vostre proprietà, potete subito trovare i duplicati perché vi troverete con due insiemi di proprietà di margin proprio una accanto all’altra. Oppure potreste preferire raggruppare le proprietà secondo la loro funzione: posizionamento, relative al box-model, etc. Mettere a punto un sistema vi aiuta a stare alla larga dalle ripetizioni.
• Migliora la performance. Ho tenuto il meglio per ultimo. La verifica del codice, insieme al combinare e zippare i fogli di stile, porta a velocità del sito nettamente più rapide. Per esempio, Harry Roberts, un front-end architect dello UK che fa audit regolarmente, mi ha detto di un sito su cui ha lavorato recentemente:
  

  Ho ricreato Fasetto.com con la volontà di migliorarne la perfromance: è passato da 27 fogli di stile separati per un sito di una sola pagina (principalmente UI toolkits come Bootstrap, etc.) fino a solo un foglio di stile (che è minimizzato e in linea, per far risparmiare delle richieste HTTP), che dopo essere stato gzippato pesa solo 5.4 KB.

Si tratta di un’enorme vittoria, specialmente per le persone sulle connessioni più lente, ma in realtà tutti ci guadagnano quando i siti si caricano rapidamente.

Come fare la verifica: fare l’inventario#section2

Ora che gli audit vi hanno convinto, come procedete per farne uno? Mi piace cominciare con alcuni tool che forniscono una visione generale di quella che è la codebase attuale del sito. Potreste approcciare il vostro audit in maniera differente, a seconda delle aree problematiche del vostro sito o la vostra filosofia di scrittura del codice (se OOCSS o BEM). La cosa importante è tenere a mente quello che sarà più utile per voi e il vostro sito.

Una volta fatta la diagnosi con i tool, esaminerò il codice riga per riga.

Tool#section3

Il primo strumento che uso sempre è l’inestimabile Type-o-matic di Nicole Sullivan, un add-on per Firebug che genera un report JSON di tutti gli stili tipografici in uso nel sito. Come bonus extra, Type-o-matic crea un report visuale mentre sta girando. Osservando entrambe i report, saprete subito quando combinare gli stili per la tipografia che sono troppo simili, eliminando gli stili non necessari. Ho scoperto che il dettaglio del report JSON rende semplice vedere come creare un sistema tipografico più riutilizzabile.

Oltre a Type-o-matic, uso CSS Lint, uno strumento estremamente flessibile che segnala una gran quantità di potenziali bug, dai colori di fallback mancanti alle proprietà shorthand per migliorare la performanc. Per usare CSS Lint, cliccate la freccia accanto alla parola “Lint” e scegliete le opzioni che desiderate. Mi piace controllare le proprietà duplicate o se ci sono troppi font size, quindi solitamente scelgo Maintainability & Duplication insieme a Performance. Quindi, CSS Lint ritorna una serie di raccomandazioni per effettuare delle modifiche: alcune possono essere collegate ai dei problemi noti che non funzionano nei browser più vecchi e altri potrebbero essere best practice (per come li vede i tool). CSS Lint non è perfetto. Se lo fate girare lasciando spuntate tutte le opzioni, potreste vedere cose nel report finale con cui non siete d’accordo, come i warning per IE6. Detto ciò, si tratta di un modo rapido per avere un’idea dello stato generale del vostro CSS.

Poi, cerco nel CSS per scoprire con che frequenza ripeto le proprietà comuni, come float o margin. (Se siete a vostro agio con la rig di comando, usate grep insieme alle istruzioni e attaccateci qualcosa tipo grep “float” styles/styles.scss per trovare tutte le istanze di “float”). Fate attenzione a qualunque proprietà potreste tagliare o inserire in altri moduli. Ordinare le proprietà è un esercizio di equilibrio: per ridurre il numero di proprietà ripetute, potreste aver bisogno di aggiungere più classi al vostro HTML, quindi dovrete calcolare questo costo in base al vostro progetto.

Mi piace fare questo step a mano, perché mi costringe a far passare il CSS per conto mio, che a sua volta mi aiuta a comprendere meglio quello che succede. Ma se avete poco tempo o se non vi sentite a vostro agio con la riga di comando, ci sono dei tool che possono facilitarvi il compito:

• CSS Dig è uno script automatizzato che gira su tutto il vostro codice per aiutarvi a vederlo visualmente. Uno strumento simile è StyleStats, in cui inserite un url per osservare il suo CSS.
• CSS Colorguard è un tool nuovissimo che gira su Node e dà in output un report basato sui vostri colori, così che possiate vedere se ci sono colori troppo simili. Questo vi aiuta a limitare la vostra palette di colori, rendendone più semplice il mantenimento in futuro.
• Dust-Me Selectors è un addon per Firebug in Firefox che trova i selettori non utilizzati.

Riga per riga#section4

Dopo aver utilizzato i vostri tool, prendetevi il tempo per leggere il CSS: vale la pena farlo per avere davvero un’idea di quel che sta accadendo. Per esempio, i commenti nel codice, che vengono saltati dai tool, potrebbero spiegare il motivo per cui persistono alcune stranezze.

Un importante aspetto che controllo due volte è la profondità dell’applicabilità, ossia per quanto si applica una stringa di un attributo. Il vostro CSS si basa molto sulla specificità? Vedete lunghe stringhe di selettori, negli stessi fogli di stile o nell’output di un preprocessore? Una alta profondità di applicabilità significa che il vostro codice richiederà una struttura HTML molto specifica perché funzionino gli stili. Se potete ridurla, avrete codice più riutilizzabile e performance più rapide.

Revisionare e raccomandare#section5

Adesso arriva il divertimento: una volta che avete i vostri dati, potete scoprire come migliorare il CSS e fare delle raccomandazioni.

Il documento di raccomandazione non deve essere di design o super formatto, ma dovrebbe essere semplice da leggere. Dividerlo in due parti è una buona idea. La prima conterrà la vostra revisione, con l’elenco delle cose che avete trovato. Se fate riferimento ai risultati di CSS Lint o Type-o-matic, assicuratevi di includere o uno screenshot o il report JSON stesso come allegato. La seconda metà conterrà le raccomandazioni in merito alle azioni da intraprendere per migliorare il codice. Può trattarsi semplicemente di un elenco, con punti tipo “Consolidate gli stili tipografici che sono strettamente collegati e create dei mixin per l’uso in tutto il sito”.

Man mano che analizzate tutte le informazioni che avete raccolto, cercate delle aree in cui potete:

• Ridurre il codice. Avete quattro insiemi diversi di stili per un call-out box, molti stili simili per i link, o davvero troppe eccezioni alla vostra griglia standard? Tutti questi sono degli ottimi candidati per degli stili modulari ripetibili. Per rendere ancora più semplice il consolidamento potete usare un preprocessore come Sass per farli diventare dei mixins o degli extend, facendo così in modo che gli stili vengano applicati quando li richiamate con una class. (Controllate solo che anche il codice in uscita sia sensato).
• Mantenere consistente il codice. Una buona verifica vi assicura che il codice aderisca alla sua propria filosofia. Se il vostro CSS è scritto basandosi su un particolare approccio, come BEM o OOCSS, è consistente? Oppure gli stili deviano di tanto in tanto e ci sono deviazioni accettabili? Assicuratevi di documentare queste eccezioni, così che gli altri componenti del vostro team ne siano a conoscenza.

Se state lavorando con un cliente, è importante, inoltre, spiegare gli approcci che preferite, così che capiscano da dove venite e quali cose potreste considerare come problematiche con il codice. Per esempio, io preferisco OOCSS, così tendo a spingere per più modularità e più riusabilità: qualche class ammucchiata non mi dà fastidio (se non state usando un preprocessore). Assicuratevi che il vostro cliente capisca che il contesto del vostro lavoro è particolarmente importante quando non si è nel team di implementazione.

Consegnate al cliente#section6

Fatto! Una volta che avrete scritto le vostre raccomandazioni (e vi sarete presi del tempo per rifletterci per essere sicuri che siano ben fondate, potete passarle al cliente. Siate preparati per qualunque domanda possa avere. Se tutto questo lavoro è destinato al vostro team, congratulazioni! Datevi da fare con la vostra lista!

Ma aspettate, perché un audit ha ben altre ricompense. Ora che avete questa fondamentale documentazione, fate un ulteriore passo in avanti: usatela come trampolino per parlare di come mantenere d’ora in poi il CSS. Se continuano a presentarsi le stesse questioni nel vostro codice, documentate come le avete risolte, così che tutti sappiano come procedere in futuro quando creeranno nuove feature o sezioni. Potreste far diventare questo documento una style guide. Un’altra cosa da considerare è la frequenza con cui rivedere il proprio audit per essere sicuri che la propria codebase rimanga immacolata. La tempistica varierà a seconda del team e del progetto, ma impostate un calendario realistico e regolare. Questa è una parte fondamentale del processo di verifica.

Fare un audit è il primo passo vitale per mantenere il vostro CSS pronto a tutto ed energico. Contribuisce anche a mantenere aggiornata la vostra documentazione, permettendo al vostro team di avere una buona idea su come procedere con le nuove feature. Quando il vostro codice è ben strutturato è più performante e tutti ne traggono beneficio. Quindi, trovate il momento, indossate il vostro miglior cappello da investigatore e cominciate!

Illustrazioni: {carlok}