Refactoring CSS: Introduzione (Parte 1)

CSS è un semplice linguaggio di fogli di stile per definire un sito Web o la presentazione di un documento. Tuttavia, questa semplicità lascia la porta aperta a molti potenziali problemi e debiti tecnici : codice gonfio, inferno di specificità, blocchi di codice duplicati con differenze minime o nulle, selettori inutilizzati rimanenti, hack non necessari e soluzioni alternative, solo per citarne alcuni.

Quel tipo di debito tecnico, se non pagato in tempo, può accumularsi e portare a gravi problemi su tutta la linea. Nella maggior parte dei casi, può causare effetti collaterali imprevisti quando si aggiungono nuovi componenti dell'interfaccia utente e rendono difficile la manutenzione della base di codice. Probabilmente hai già lavorato a un progetto con una base di codice CSS scadente e hai pensato a come avresti scritto il codice in modo diverso, data l'opportunità di refactoring o riscrivere tutto da zero.

Il refactoring di grandi parti del codice CSS non è un compito facile in alcun modo. A volte, può sembrare che si tratti solo di "eliminare il codice di scarsa qualità, scrivere CSS migliori e distribuire il codice migliorato brillante". Tuttavia, ci sono molti altri fattori da considerare, come la difficoltà di refactoring di una base di codice attiva, la durata prevista e l'utilizzo del team, la definizione di obiettivi di refactoring, il monitoraggio dell'efficacia e del progresso del refactoring, ecc. C'è anche la questione di convincere la direzione o le parti interessate del progetto a investire tempo e risorse nel processo di refactoring.

In questa serie di tre parti , analizzeremo il processo di refactoring CSS dall'inizio alla fine, iniziando con le conoscenze su come affrontarlo e alcuni pro e contro generali del refactoring, quindi passando alle strategie di refactoring stesse e finendo con alcune best practice generali sulle dimensioni e le prestazioni dei file CSS.

Effetti collaterali di CSS di scarsa qualità

Nonostante tutta la sua flessibilità e semplicità, lo stesso CSS presenta alcuni problemi fondamentali che consentono agli sviluppatori di scrivere codice di scarsa qualità in primo luogo. Questi problemi derivano dalla sua specificità e dai meccanismi di ereditarietà, che operano in ambito globale, dipendenza dall'ordine di origine, ecc.

A livello di team, la maggior parte dei problemi relativi alla base di codice CSS di solito derivano dai vari livelli di abilità e conoscenza CSS, preferenze e stili di codice diversi, mancanza di comprensione della struttura del progetto e del codice e dei componenti esistenti, assenza di livello di progetto o di team standard e linee guida di livello, e così via.

Di conseguenza, CSS di scarsa qualità possono causare problemi che vanno oltre i semplici bug visivi e possono produrre vari effetti collaterali gravi che possono influenzare il progetto nel suo insieme. Alcuni di questi esempi includono:

• Diminuzione della qualità del codice man mano che vengono aggiunte più funzionalità a causa dei vari livelli di abilità CSS all'interno di un team di sviluppo e della mancanza di regole, convenzioni e best practice interne.
• L'aggiunta di nuove funzionalità o l'estensione dei selettori esistenti causa bug ed effetti collaterali imprevisti in altre parti del codice (noto anche come regressione ).
• Più selettori CSS diversi con blocchi di codice duplicati o blocchi di codice CSS possono essere separati in un nuovo selettore ed estesi per variazione.
• Blocchi di codice rimanenti e inutilizzati dalle funzioni eliminate . Il team di sviluppo ha perso traccia di quale codice CSS viene utilizzato e quale può essere rimosso in sicurezza.
• Incoerenza nella struttura del file, denominazione delle classi CSS, qualità complessiva dei CSS, ecc.
• "Inferno di specificità" in cui vengono aggiunte nuove funzionalità sovrascrivendo invece di esistere la base di codice CSS.
• Annullamento del CSS in cui i selettori a specificità superiore "reimpostano" lo stile del selettore a specificità inferiore. Gli sviluppatori scrivono più codice per avere meno stili. Ciò si traduce in ridondanza e molto spreco di codice.

Negli scenari peggiori, tutti i problemi summenzionati combinati possono comportare una dimensione del file CSS di grandi dimensioni , anche con la minimizzazione CSS applicata. Questo CSS di solito blocca il rendering, quindi il browser non eseguirà nemmeno il rendering del contenuto del sito Web fino a quando non avrà terminato il download e l'analisi del file CSS, risultando in una UX e prestazioni scadenti su reti più lente o inaffidabili.

Questi problemi non riguardano solo l'utente finale, ma anche il team di sviluppo e le parti interessate del progetto, rendendo la manutenzione e lo sviluppo delle funzionalità difficili, dispendiosi in termini di tempo e costosi. Questo è uno degli argomenti più utili da sollevare quando si discute per il refactoring o la riscrittura CSS.

Il team di Netlify ha notato che il motivo alla base del loro progetto di refactoring CSS su larga scala era la diminuzione della qualità e della manutenibilità del codice man mano che il progetto cresceva in complessità con l'aggiunta di un numero sempre maggiore di componenti dell'interfaccia utente. Hanno anche notato che la mancanza di standard CSS interni e documentazione ha portato alla diminuzione della qualità del codice poiché sempre più persone stavano lavorando sulla base di codice CSS.

“(…) ciò che è iniziato con PostCSS organizzato è gradualmente cresciuto fino a diventare un'architettura CSS globale complessa e intricata con molte specificità e sostituzioni. Come ci si potrebbe aspettare, c'è un punto in cui il debito tecnologico aggiuntivo che introduce rende difficile continuare a spedire velocemente senza aggiungere regressioni. Inoltre, poiché cresce anche il numero di sviluppatori frontend che contribuiscono alla base di codice, questo tipo di architettura CSS diventa ancora più difficile da lavorare".

Refactor o riscrivere?

Il refactoring consente agli sviluppatori di migliorare gradualmente e strategicamente la base di codice esistente, senza modificarne la presentazione o le funzionalità principali. Questi miglioramenti sono in genere di portata ridotta e limitati e non introducono modifiche all'architettura di ampia portata e non aggiungono nuovi comportamenti, funzionalità o funzionalità alla base di codice esistente.

Ad esempio, l'attuale codebase presenta due varianti di un componente della scheda: la prima è stata implementata all'inizio dello sviluppo del progetto da uno sviluppatore esperto e la seconda è stata aggiunta qualche tempo dopo che il progetto è stato lanciato da uno sviluppatore meno esperto con una scadenza breve, quindi è dotato di codice duplicato e selettori ad ampio raggio con alta specificità.

È necessario aggiungere una terza variante di carta, che condivide alcuni stili delle altre due varianti di carte. Quindi, al fine di evitare bug, codice duplicato e classi CSS complesse e markup HTML su tutta la linea, il team decide di refactoring del componente CSS della carta prima di implementare una nuova variazione.

La riscrittura consente agli sviluppatori di apportare modifiche sostanziali alla base di codice e presuppone che la maggior parte, se non tutto il codice della base di codice corrente, verrà modificata o sostituita. Rewrite consente agli sviluppatori di creare la nuova base di codice da zero, affrontare i problemi principali della base di codice corrente che erano impossibili o costosi da risolvere, migliorare lo stack tecnologico e l'architettura e stabilire nuove regole interne e best practice per la nuova base di codice.

Ad esempio, il cliente è in fase di rebranding e il sito Web deve essere aggiornato con un nuovo design e contenuti rinnovati. Poiché si tratta di un cambiamento immediato a livello di sito, gli sviluppatori decidono di ricominciare da zero, riscrivere il progetto e cogliere questa opportunità per affrontare i problemi principali che l'attuale codebase CSS ha ma non può essere risolto con il refactoring del codice, aggiorna lo stack tecnologico CSS , utilizza gli strumenti e le funzionalità più recenti, stabilisci nuove regole interne e le migliori pratiche per lo styling, ecc.

Riassumiamo i pro ei contro di ogni approccio.

Quando eseguire il refactoring CSS?

Il refactoring è un approccio consigliato per migliorare in modo incrementale la base di codice CSS mantenendo l'aspetto (design) attuale. I membri del team possono lavorare per risolvere questi problemi di codebase quando non ci sono attività con priorità più alta. Migliorando in modo incrementale l'esperienza utente della base di codice corrente non sarà direttamente influenzata nella maggior parte dei casi, tuttavia, una base di codice più pulita e manutenibile risulterà in un'implementazione delle funzionalità più semplice e in un minor numero di bug ed effetti collaterali imprevisti.

Gli stakeholder del progetto probabilmente accetteranno di investire tempo e risorse limitati nel refactoring, ma si aspettano che queste attività vengano eseguite rapidamente e si aspettano che il team sia disponibile per le attività primarie.

Il refactoring CSS dovrebbe essere eseguito a intervalli regolari quando non sono previste modifiche di design o contenuto ad ampio raggio per il prossimo futuro. I team dovrebbero cercare in modo proattivo i punti deboli menzionati in precedenza nell'attuale codebase CSS e lavorare per affrontarli ogni volta che non sono disponibili attività con priorità più elevata.

Lo sviluppatore frontend principale o lo sviluppatore con la maggiore esperienza con CSS dovrebbe sollevare problemi e creare attività di refactoring per applicare gli standard di qualità del codice CSS nella base di codice.

Quando riscrivere il CSS?

La riscrittura della base di codice CSS completa dovrebbe essere eseguita quando la base di codice CSS presenta problemi fondamentali che non possono essere risolti con il refactoring o quando il refactoring è un'opzione più costosa. Parlando per esperienza personale, quando ho iniziato a lavorare per clienti che si sono trasferiti da un'altra azienda e i suddetti problemi CSS ed era ovvio che sarebbe stato un lavoro difficile da refactoring, ho iniziato raccomandando una riscrittura completa e vedere cosa pensa il cliente. Nella maggior parte dei casi, quei clienti erano insoddisfatti dello stato della base di codice ed erano felici di procedere con la riscrittura.

Un altro motivo per la riscrittura completa dei CSS è quando è pianificata una modifica sostanziale per il sito Web: rebranding, riprogettazione o qualsiasi altra modifica significativa che influisca sulla maggior parte del sito Web. È lecito ritenere che le parti interessate del progetto siano consapevoli che si tratta di un investimento significativo e che ci vorrà del tempo prima che la riscrittura sia completa.

Verifica dell'integrità della base di codice CSS

Quando il team di sviluppo ha concordato sul fatto che il codice CSS deve essere rifattorizzato per semplificare il flusso di lavoro di sviluppo delle funzionalità o eliminare gli effetti collaterali e i bug CSS imprevisti, il team deve presentare questo suggerimento alle parti interessate del progetto o a un project manager.

È una buona idea fornire alcuni dati concreti insieme ai pensieri soggettivi sulla base di codice e alla revisione generale del codice. Ciò darà anche al team un obiettivo misurabile di cui possono essere consapevoli mentre lavorano al refactor: dimensione del file di destinazione, specificità del selettore, complessità del codice CSS, numero di query multimediali...

Quando eseguo un audit CSS o mi preparo per un refactor CSS, mi affido a molti dei molti strumenti utili per ottenere una panoramica generale e statistiche utili sulla base di codice CSS.

Il mio strumento personale di riferimento è CSS Stats, uno strumento gratuito che fornisce un'utile panoramica della qualità della base di codice CSS con molte metriche utili che possono aiutare gli sviluppatori a rilevare alcuni problemi difficili da individuare.

Nel 2016, trivago ha eseguito un refactoring su larga scala per la propria base di codice CSS e ha utilizzato le metriche di CSS Stats per stabilire alcuni obiettivi concreti e misurabili come ridurre la specificità e il numero di variazioni di colore. In sole tre settimane, sono riusciti a migliorare lo stato generale della base di codice CSS, ridurre le dimensioni del file CSS, migliorare le prestazioni di rendering su dispositivi mobili, ecc.

“Uno strumento come CSS Stats può aiutarti a capire facilmente i problemi di coerenza all'interno della tua base di codice. Indicando cosa può succedere quando ognuno ha opinioni diverse su come dovrebbe apparire un tono di grigio, ti ritroverai con 50 sfumature di grigio. Inoltre, il grafico di specificità ti dà una buona indicazione generale dello stato di salute della tua base CSS.

Per quanto riguarda gli strumenti CLI, Wallace è uno strumento utile che fornisce statistiche CSS e una panoramica piuttosto semplici ma utili che possono essere utilizzate per identificare problemi relativi alla dimensione del file, al numero di regole e selettori, tipi di selettore e complessità, ecc.

Wallace offre anche uno strumento di analisi gratuito sul sito Web di Project Wallace che utilizza una versione apparentemente più avanzata di Wallace nel back-end per fornire alcune visualizzazioni di dati utili e alcune metriche in più che non sono disponibili nella CLI di Wallace.

Project Wallace offre anche una soluzione completa a pagamento per l'analisi della base di codice CSS . Presenta funzionalità e metriche ancora più utili che possono aiutare gli sviluppatori a rilevare alcuni problemi difficili da individuare e tenere traccia delle modifiche alle statistiche CSS in base al commit. Sebbene il piano a pagamento includa più funzionalità, il piano gratuito e lo strumento di analisi CSS di base sono più che sufficienti per controllare la qualità della base di codice CSS e ottenere una panoramica generale per pianificare il refactoring.

Scrivere CSS di alta qualità

Abbiamo visto come la semplicità e la flessibilità della base di codice CSS possono causare molti problemi con la qualità del codice, le prestazioni e i bug visivi. Non esiste uno strumento automatico di punta d'argento che si assicurerà di scrivere CSS nel miglior modo possibile ed evitare tutte le possibili insidie ​​architettoniche lungo il percorso.

I migliori strumenti che ci assicureranno di scrivere codice CSS di alta qualità sono la disciplina, l'attenzione ai dettagli e le conoscenze e le competenze CSS generali . Lo sviluppatore deve essere costantemente consapevole del quadro più ampio e capire quale ruolo gioca il loro CSS in quel quadro più ampio.

Ad esempio, specificando eccessivamente i selettori, un singolo sviluppatore può limitare gravemente l'usabilità, portando altri sviluppatori a dover duplicare il codice per usarlo per altri componenti simili con markup diverso. Questi problemi si verificano spesso quando gli sviluppatori non comprendono e non sfruttano i meccanismi alla base dei CSS (cascata, ereditarietà, prestazioni del browser e specificità del selettore). Queste prime decisioni possono portare a importanti ripercussioni in futuro , quindi la salute e la manutenibilità della base di codice CSS dipendono dalle conoscenze, abilità e comprensione dei fondamenti CSS dello sviluppatore.

Gli strumenti automatizzati non sono a conoscenza del quadro più ampio o di come viene utilizzato il selettore, quindi non possono prendere queste decisioni architettoniche cruciali, oltre a far rispettare alcune regole di base, prevedibili e rigide.

Parlando per esperienza personale, ho scoperto che quanto segue mi ha aiutato a migliorare significativamente il modo in cui ho lavorato con CSS:

• Imparare i modelli architettonici.
  Le linee guida CSS forniscono un'ampia base di conoscenze e le migliori pratiche per la scrittura di CSS di alta qualità basati su modelli di programmazione generali e principi architetturali.
• Pratica e migliora.
  Lavora su progetti personali o affronta una sfida di Frontend Mentor per migliorare le tue abilità. Inizia con progetti semplici (un singolo componente o una sezione) e concentrati sulla scrittura del miglior CSS possibile, prova vari approcci, applica vari modelli architetturali, migliora gradualmente il codice e impara a scrivere CSS di alta qualità in modo efficiente.
• Imparare dagli errori.
  Credimi, scriverai dei CSS di qualità davvero scadente quando inizi. Ci vorranno alcuni tentativi per farlo bene. Prenditi un momento e pensa a cosa è andato storto, analizza i punti deboli, pensa a cosa avresti potuto fare diversamente e come, e cerca di evitare gli stessi errori in futuro.

È anche importante stabilire regole e standard CSS interni all'interno di un team o anche per l'intera azienda. Standard aziendali, stile del codice e principi chiaramente definiti possono produrre molti vantaggi come:

• Stile e qualità del codice unificati e coerenti
• Base di codice più facile da capire e robusta
• Onboarding del progetto semplificato
• Revisioni del codice standardizzate che possono essere eseguite da qualsiasi membro del team, non solo dallo sviluppatore frontend principale o dagli sviluppatori più esperti

Kirby Yardley ha lavorato al refactoring del sistema di progettazione del Sundance Institute e dei CSS e ha sottolineato l'importanza di stabilire regole interne e migliori pratiche.

“Senza regole e strategie adeguate, i CSS sono un linguaggio che si presta a un uso improprio. Spesso gli sviluppatori scrivono stili specifici per un componente senza pensare in modo critico a come quel codice potrebbe essere riutilizzato in altri elementi (...) Dopo molte ricerche e riflessioni su come volevamo avvicinarci all'architettura del nostro CSS, abbiamo deciso di utilizzare una metodologia chiamata ITCSS. “

Tornando all'esempio precedente del team di trivago, stabilire regole e linee guida interne si è rivelato un passo importante per il loro processo di refactoring.

"Abbiamo introdotto una libreria di modelli, iniziato a utilizzare la progettazione atomica nel nostro flusso di lavoro, creato nuove linee guida di codifica e adattato diverse metodologie come BEM e ITCSS per supportarci nel mantenimento e nello sviluppo della nostra CSS/UI su larga scala".

Non tutte le regole e gli standard devono essere controllati e applicati manualmente. Gli strumenti CSS linting come Stylelint forniscono alcune regole utili che ti aiuteranno a verificare la presenza di errori e a far rispettare gli standard interni e le migliori pratiche CSS comuni come non consentire blocchi e commenti di codice CSS vuoti, non consentire selettori duplicati, limitare le unità, impostare la specificità massima del selettore e la profondità di annidamento, stabilire modello del nome del selettore, ecc.

Conclusione

Prima di decidere di proporre un refactor granulare della base di codice o una riscrittura CSS completa, è necessario comprendere i problemi con la base di codice corrente in modo da poterli evitare in futuro e disporre di dati misurabili per il processo. La base di codice CSS può contenere molti selettori complessi ad alta specificità che causano effetti collaterali e bug imprevisti quando si aggiungono nuove funzionalità, forse la base di codice soffre di molti blocchi di codice ripetuti che possono essere spostati in una classe di utilità separata, o forse il mix di varie media query stanno causando alcuni conflitti imprevisti.

Strumenti utili come CSS Stats e Wallace possono fornire una panoramica generale di alto livello della base di codice CSS e fornire una visione dettagliata dello stato e della salute della base di codice. Questi strumenti forniscono anche statistiche misurabili che possono essere utilizzate per definire gli obiettivi per il processo di refactoring e tenere traccia dei progressi del refactoring.

Dopo aver determinato gli obiettivi e l'ambito del refactoring, è importante definire le linee guida interne e le migliori pratiche per la base di codice CSS : convenzione di denominazione, principi architetturali, struttura di file e cartelle, ecc. Ciò garantisce la coerenza del codice, stabilisce una base fondamentale all'interno del progetto che può essere documentata e che può essere utilizzato per l'onboarding e la revisione del codice CSS. L'uso di strumenti di linting come Stylelint può aiutare a far rispettare alcune best practice CSS comuni per automatizzare parzialmente il processo di revisione del codice.

Nel prossimo articolo di questa serie in tre parti, ci addentreremo in una strategia di refactoring CSS a prova di proiettile che garantisce una transizione senza interruzioni tra la base di codice corrente e la base di codice refactored.

Riferimenti

• "Gestire i progetti CSS con ITCSS", Harry Roberts
• "Refactoring CSS su larga scala presso Trivago", Christoph Reinartz
• "Sistema di progettazione Sundance.org e refactoring CSS", Kirby Yardley
• "Dal CSS semantico a Tailwind: refactoring della base di codice dell'interfaccia utente di Netlify", Charlie Gerard e Leslie Cohn-Wein
• "Strumenti di audit CSS", Iris Lješnjanin