Come Refactor CSS - Una guida

Il refactoring CSS deve essere una parte essenziale del flusso di lavoro di sviluppo front-end, se vogliamo avere una base di codice gestibile e ottimizzata. Quando rifattiamo i CSS, noi ripulire e riorganizzare il nostro codice esistente senza aggiungere nuove funzionalità o correggere bug.

Aiuto per il refactoring prevenire l'esplosione CSS, migliora la leggibilità del codice e la riusabilità, e rende CSS più veloce e veloce da eseguire.

Di solito, dopo un po 'di tempo è necessario ricorrere al refactoring, perché anche i progetti che iniziano con una base di codice concisa e organizzata prima o poi iniziano a perdere la loro chiarezza; coerenza, regole obsolete e parti di codice duplicate appaiono; e iniziamo anche a scavalcare stili e impiegare sempre più hack e soluzioni alternative.

Il modo migliore per mantenere la nostra base di codici CSS manutenibile è attenersi a “refactore anticipato, refactor spesso” regola del pollice. In questo post daremo un'occhiata ad alcuni suggerimenti su come possiamo condurre un efficace processo di refactoring CSS.

1. Effettuare un audit iniziale

Per avere un quadro migliore di ciò che abbiamo bisogno di refactoring, è il migliore iniziare con un audit completo per vedere cosa abbiamo attualmente.

Ci sono molti ottimi strumenti online che possono aiutarci in questo sforzo. CSSDig è una potente estensione di Chrome che analizza il CSS di un sito web ed esplora i suoi punti deboli, come selettori troppo specifici o proprietà ripetitive.

I CSS non utilizzati analizzano le regole CSS inutilizzate, mentre gli strumenti di linting, come CSS Lint, consentono di trovare rapidamente compatibilità, manutenibilità e altri problemi.

È anche importante scrutare manualmente il codice durante l'audit iniziale, poiché molti problemi a livello di architettura possono essere catturati solo in questo modo.

2. Imposta un piano gestibile

Rifare il codice di lavoro è sempre un compito arduo, ma possiamo alleviare il dolore se creiamo un piano su ciò che dobbiamo fare, suddividiamo il processo di refactoring in blocchi gestibili e facciamo un programma fattibile.

Nel refactoring dei CSS c'è una cosa fondamentale che dobbiamo sempre prendere in considerazione: alcune cose che noi refactoring, ad es. cambiare i nomi dei selettori, ce la farà necessario per regolare il codice dei file HTML e JavaScript pertinenti anche.

È quindi una buona idea rintracciare queste ulteriori modifiche che dovremo eseguire, e costruiscili nel nostro programma di refactoring insieme con le attività primarie relative ai CSS.

3. Monitora il progresso

Prima di iniziare il refactoring, è un passo essenziale per eseguire il backup dei nostri file iniziali. L'introduzione di un sistema di controllo della versione, come Git o Subversion, nel nostro flusso di lavoro può anche migliorare significativamente il processo di refactoring, poiché avremo un registro sui passi sequenziali che abbiamo intrapreso e sarà in grado di tornare a una fase precedente se vogliamo ripetere le cose.

4. Attenersi a una guida allo stile di codifica

Una guida coerente allo stile di codifica può migliorare notevolmente la leggibilità e la manutenibilità del codice, quindi prima di iniziare a fare il refactoring è essenziale impostare una guida di stile per la codifica CSS.

Le cose importanti da decidere sono:

• convenzioni di denominazione
• regole di formattazione
• ordine di dichiarazione
• unità e valori che vogliamo usare
• regole di commento

Se non vogliamo creare la nostra guida allo stile di codifica, possiamo anche usare quelli di qualcun altro, come quelli di ThinkUp che possono essere trovati su Github.

Non è sufficiente però introdurre una guida allo stile di codifica, ma è anche necessario attenersi ad esso quando riscriviamo il codice durante il refactoring, e aspettarsi lo stesso da tutti gli altri chi lavora al nostro progetto.

5. Configurare una struttura di file coerente

Dopo essere pronti con i preparativi, la prima cosa che dobbiamo fare è impostare una struttura di file CSS adeguata che presta attenzione alla natura a cascata dei CSS.

Dipende principalmente dal progetto sul modo migliore di organizzare i nostri file, ma ci sono alcune regole universali, come l'uso di un separato normalize.css file per stili di reset CSS, un separato global.css per gli stili globali utilizzati nell'intero progetto e per archiviare le librerie di terze parti in una cartella separata.

Se vogliamo giocare sicuri con la nostra struttura di file CSS, ci sono anche architetture già pronte, come SMACSS o ITCSS, che offrono tecniche efficaci su come organizzare i file CSS in modo scalabile.

6. Eliminare le regole inutilizzate e duplicate

Dopo un po ', i file CSS di solito iniziano ad abbondare in regole inutilizzate che dobbiamo identificare e ripulire durante il refactoring. Ci sono molti strumenti online che ci consentono di indagare su queste regole obsolete, e talvolta ci permettono anche di abbandonarli rapidamente.

Lo strumento più noto a questo scopo è probabilmente UnCSS, un modulo Node.js che consente di eliminare rapidamente le regole CSS inutilizzate e fornisce anche opzioni di configurazione sofisticate che semplificano la messa a punto del processo di pulizia.

È importante tenere conto che noi non necessariamente vuole rimuovere le regole inutilizzate da tutti i file CSS che abbiamo, ad esempio da fogli di stile globali, ripristinati o di terze parti, quindi è necessario escluderli durante l'esecuzione della pulizia.

Insieme alle regole obsolete, le regole duplicate portano anche a un eccesso di codice superfluo e alla perdita di prestazioni. Possiamo rimuoverli usando il modulo CSS Purge Node.js, ma possiamo anche lavorare con Linter CSS per cercare regole duplicate nei nostri file CSS.

7. Riduci la specificità

La specificità di un selettore CSS viene calcolata dal numero e dai tipi dei selettori interni che contiene. La specificità CSS è espressa come un numero a 4 cifre che è la più facile da capire se verifichiamo questo calcolatore di specificità CSS visivo:

La più bassa specificità (0001) appartiene ai selettori che hanno come target solo un elemento HTML generale, come ad esempio

o

. Più selettori interni contengono un selettore composto, maggiore è la sua specificità.

Alcuni selettori, come ad esempio id o i selettori che provengono da stili in linea hanno priorità più elevate perché sostituiscono gli stili appartenenti a selettori più generici. Ad esempio la specificità del # id1 il selettore è 0100.

Nel refactoring, l'obiettivo è quello di diminuire la specificità dei selettori (tenerli corti) il più possibile, come i selettori con maggiore specificità riducono significativamente la riusabilità del selettore, e portare a una base di codice gonfio.

I 3 tipi principali di selettori ad alta specificità sono:

1. Selettori qualificati, ad esempio p.class1 (definendo il p il tag non è necessario qui, in quanto rende impossibile l'uso della stessa classe con altri elementi HTML)
2. Selettori profondamente annidati, ad esempio .class1 .class2 .class3 .class4 ...
3. ID, ad esempio # id1

Gli strumenti online, come CSSDig menzionati nel passaggio 1, possono essere utilizzati per trovare rapidamente questi selettori ad alta specificità. Può anche essere utile impostare una regola nella guida allo stile di codifica su cose come il livello massimo di nidificazione o un limite all'uso id selettori.

8. Weed Out !importante Regole

Regole CSS seguite dal !importante la dichiarazione sostituisce le regole di stile regolari. utilizzando !importante regole prima o poi portare a codice incoerente. Non è un caso che la maggior parte degli strumenti di pelatura li segnali come un errore.

Quando abbiamo bisogno di scrivere rapidamente i CSS, possiamo iniziare a fare affidamento su di essi anche se per la loro semplicità.

Il problema principale con !importante le dichiarazioni dicono che se vogliamo scavalcarle in futuro, dobbiamo metterne ancora di più !importante dichiarazioni in uso, quindi è meglio eliminarle ovunque sia possibile durante il processo di refactoring.

9. Pulisci i numeri magici e i valori hard coded

Durante il nostro flusso di lavoro CSS quotidiano, a volte ci imbattiamo in problemi che non possiamo risolvere e iniziamo a utilizzare i cosiddetti numeri magici, valori che funzionano per alcune ragioni ma non capiamo perché. Ad esempio, prendi il seguente esempio:

 .class1 position: absolute; superiore: 28 px; a sinistra: 15,5%; 

Il problema principale con i numeri magici è che lo sono circostanziato, e incarnano il “programmazione per permutazione” antipattern. Durante il processo di refactoring dobbiamo rimuovere queste regole arbitrarie dal nostro codice e sostituirle con soluzioni più ragionevoli dovunque sia possibile.

Si applica la stessa regola generale valori hardcoded anche. Probabilmente l'occorrenza più frequente di valori codificati può essere trovata nelle regole dell'altezza della linea:

 / * male, avremo bisogno di aggiungere regole extra di altezza della linea agli elementi figli di .class1 * / .class1 font-size: 20px; altezza della linea: 24px;  / * bene, la regola flessibile dell'altezza della riga può essere utilizzata in sicurezza anche da elementi figlio * / .class1 font-size: 20px; altezza della linea: 1,2; 

I valori hard-coded rendono il nostro codice meno a prova di futuro e più rigido, quindi come parte del refactoring dobbiamo scavare e sostituirli con valori flessibili.

10. Unità e valori di refactoring

Rendere più facile la manutenzione e il debugging in futuro e per evitare guasti che possono derivare dall'utilizzo di unità diverse, come ad esempio em e px, allo stesso tempo, abbiamo bisogno di attenersi a regole coerenti su come utilizziamo valori relativi e assoluti.

Se li abbiamo usati in modo incoerente in passato, abbiamo bisogno di convertirli in modo che possano costituire un sistema conciso

Se usiamo troppi colori simili sul nostro sito, può anche essere una cosa saggia razionalizzare lo schema dei colori riducendo il numero di colori che impieghiamo. (Ecco un post su come scegliere una combinazione di colori del sito web in modo pratico.)