Hur Refactor CSS - En Guide

CSS refactoring behöver vara en väsentlig del av utvecklingsprocessen för framsidan, om vi vill ha en hanterbar och optimerad kodbas. När vi refactor CSS, vi städa upp och omorganisera vår befintliga kod utan att lägga till några nya funktioner eller fixa buggar.

Refactoring hjälper förhindra CSS-explosion, förbättrar kodläsbarhet och återanvändbarhet, och gör CSS snyggare och snabbare att utföra.

Refactoring behövs vanligtvis efter ett tag, eftersom även projekt som startade med en kortfattad och organiserad kodbas förr eller senare börjar förlora sin klarhet; konsistens, föråldrade regler och duplicerade koddelar visas; och vi börjar också åsidosätta stilar och använda fler och fler hackar och lösningar.

Det bästa sättet att behålla vår CSS-kodbas är att hålla sig till “refaktor tidigt, refactor ofta” tumregel. I det här inlägget tar vi en titt på några tips om hur vi kan genomföra en effektiv CSS-refaktorprocess.

1. Utför en inledande revision

För att få en bättre bild om vad vi behöver refactor är det bäst att börja med en omfattande revision för att se vad vi för närvarande har.

Det finns många bra onlineverktyg som kan hjälpa oss i detta arbete. CSSDig är en kraftfull Chrome-förlängning som analyserar CSS på en webbplats och utforskar dess svagheter, som för specifika selektorer eller repeterande egenskaper.

Oanvänd CSS undersöker oanvända CSS-regler, medan lintingverktyg, till exempel CSS Lint, gör det möjligt att snabbt hitta kompabilitet, underhåll och andra problem.

Det är också viktigt att man manuellt granskar koden under den ursprungliga revisionen, eftersom många problem på arkitektonisk nivå endast kan fångas på detta sätt.

2. Skapa en hanterbar plan

Refactoring arbetskod är alltid en skrämmande uppgift, men vi kan lindra smärtan om vi skapar en plan om vad vi behöver göra, skiv upp refactoringprocessen till hanterbara bitar och gör ett genomförbart schema.

I CSS refactoring är det en viktig sak som vi alltid behöver ta hänsyn till: vissa saker som vi refactor, t.ex. byter väljarnamn, kommer att göra det nödvändigt för att justera koden för relevanta HTML- och JavaScript-filer också.

Det är därför en bra idé att spåra dessa ytterligare modifieringar som vi behöver utföra, och bygga dem i vårt refactoring schema tillsammans med de primära, CSS-relaterade uppgifterna.

3. Spårframsteg

Innan vi påbörjar refactoring är det ett viktigt steg till säkerhetskopiera våra ursprungliga filer. Att introducera ett versionsstyrningssystem, till exempel Git eller Subversion, i vårt arbetsflöde, kan också förbättra refactoringprocessen avsevärt, eftersom vi får ett register om de sekventiella stegen vi har tagit och vi kommer att kunna återgå till ett tidigare skede om vi vill göra om saker.

4. Håll dig till en kodningsstylguide

En sammanhängande kodningsstilguide kan påtagligt förbättra kodläsbarheten och underhållet, så innan vi börjar refactor är det viktigt att skapa en CSS kodning stil guide.

De viktiga sakerna att bestämma är:

• namnkonventioner
• formateringsregler
• förklaringsorder
• enheter och värden vi vill använda
• kommentarregler

Om vi ​​inte vill skapa vår egen kodningsstilguide kan vi också använda någon annans, till exempel ThinkUp som kan hittas på Github.

Det räcker inte för att bara introducera en kodningsstilguide, vi behöver också hålla fast vid det när vi skriver om koden under refactoring, och Förvänta dig samma från alla andra vem arbetar med vårt projekt.

5. Konfigurera en sammanhängande filstruktur

När vi är redo för förberedelserna är det första vi behöver göra för att skapa en riktig CSS-filstruktur som uppmärksammar CSS.

Det beror främst på projektet hur man bäst organiserar våra filer, men det finns några universella regler, som att använda en separat normalize.css fil för CSS återställningsstilar, en separat global.css för globala stilar som används över hela projektet och för att lagra tredje partsbibliotek i en separat mapp.

Om vi ​​vill spela säkert med vår CSS-filstruktur finns det också färdiga arkitekturer, såsom SMACSS eller ITCSS, som erbjuder effektiva tekniker om hur man organiserar CSS-filer på ett skalbart sätt.

6. Bli av med oanvända och duplicerade regler

Efter ett tag börjar CSS-filer oftast överflöda i oanvända regler som vi behöver identifiera och städa ut under refactoring. Det finns många onlineverktyg som gör att vi kan undersöka dessa föråldrade regler, och tillåter oss ibland också att snabbt dike dem.

Det mest kända verktyget för detta ändamål är förmodligen UnCSS, en Node.js-modul som gör det möjligt att snabbt avinstallera oanvända CSS-regler, och det ger oss också sofistikerade konfigurationsalternativ som gör det enkelt att finjustera rengöringsprocessen.

Det är viktigt att ta hänsyn till att vi vill inte nödvändigtvis ta bort oanvända regler från Allt de CSS-filer vi har, till exempel från globala, återställda eller tredje part stilark, så vi behöver utesluta dem under rengöringen.

Tillsammans med föråldrade regler leder dubbla regler också till överflödig kodblåsning och prestandaförlust. Vi kan ta bort dem med hjälp av CSS Purge Node.js-modulen, men vi kan också arbeta med CSS-linjer för att söka efter dubbla regler i våra CSS-filer.

7. Minska specificiteten

Specificiteten hos en CSS-väljare beräknas utifrån antalet och typerna av de inre selektorerna som den innehåller. CSS-specificitet uttrycks som ett fyrsiffrigt nummer som är lättast att förstå om vi kolla in den här visuella CSS-specificitetsräknaren:

Den lägsta specificiteten (0001) tillhör selektorer som endast riktar mot ett generellt HTML-element, till exempel

eller

. Ju mer inre selektorer en sammansättningsväljare innehåller desto högre är dess specificitet.

Vissa väljare, t.ex. id eller väljare som kommer från inline-stilar, har högre prioriteringar eftersom de strider mot stilar som hör till fler generiska väljare. Till exempel specificiteten av # id1 väljaren är 0100.

I refactoring är målet att minska selektornas specificitet (håll dem korta) så mycket som möjligt selektorer med högre specificitet reducerar väljbar återanvändbarhet avsevärt, och leda till en uppblåst kodbas.

De tre huvudtyperna av high specificity selectors är:

1. Kvalificerade väljare, som p.class1 (definierar p taggen är onödig här, eftersom det gör det omöjligt att använda samma klass med andra HTML-element)
2. Djupt nestade selektorer, som .class1 .class2 .class3 .class4 ...
3. ID, som # id1

Onlineverktyg, som CSSDig som nämns i steg 1, kan användas för att snabbt hitta dessa high specificity selectors. Det kan också vara användbart att ställa in en regel i kodningsstilguiden om saker som den maximala nestningsgraden eller en gräns för att använda id selektorer.

8. Weed Out !Viktig regler

CSS regler följt av !Viktig uttalandet åsidosätter regelbundna stilregler. Använder sig av !Viktig reglerar förr eller senare leda till inkoherent kod. Det är inte en slump att de flesta lintingverktyg markerar dem som fel.

När vi behöver skriva CSS snabbt kan vi börja använda sig av dem på grund av deras enkelhet.

Det största problemet med !Viktig deklarationer är att om vi vill åsidosätta dem i framtiden måste vi lägga ännu mer !Viktig deklarationer som används, så det är bäst att linda dem ut varhelst det är möjligt under refactoringprocessen.

9. Rengör Magic Numbers och hårdkodade värden

Under vårt vardagliga CSS-arbetsflöde stöter vi ibland på problem vi inte kan lösa, och vi börjar använda så kallade magiska tal, värden som fungerar av vissa skäl men vi förstår inte varför. Ta till exempel följande exempel:

 .klass1 position: absolut; topp: 28px; vänster: 15,5%; 

Det största problemet med magiska nummer är att de är omständlig, och de förkroppsligar “programmering genom permutation” antimönster. Under refactoringprocessen måste vi ta bort dessa godtyckliga regler från vår kod och ersätta dem med mer rimliga lösningar varhelst det är möjligt.

Samma tumregel gäller för hårdkodade värden också. Förmodligen kan den vanligaste förekomsten av hårdkodade värden hittas i linjehöjdsregler:

 / * dålig, vi måste lägga till extra regler för fast linjehöjd till barnelementen i .class1 * / .class1 font-size: 20px; linjehöjd: 24px;  / * bra, den flexibla linjehöjdsregeln kan även användas säkert av barnelement * / .class1 font-size: 20px; linjehöjd: 1,2; 

Hårdkodade värden gör vår kod mindre framtidssäker och mer stel, så som en del av refactoring behöver vi gräva dem och ersätt dem med flexibla värden.

10. Refactor Units och värden

För att underlätta underhåll och felsökning i framtiden, och för att undvika fel som kan härröra från att använda olika enheter, t.ex. em och px, samtidigt måste vi hålla fast vid sammanhängande regler om hur vi använder relativa och absoluta värden.

Om vi ​​använt dem inkonsekvent tidigare måste vi konvertera dem så att de kan utgöra ett kortfattat system

Om vi ​​använder för många liknande färger på vår webbplats kan det också vara en klok sak att rationalisera färgschemat genom att minska antalet färger vi använder. (Här är ett inlägg om hur man väljer ett webbsidor färgschema på ett praktiskt sätt.)