Hvordan Refactor CSS - En Guide
CSS refactoring må være en viktig del av utviklingsprosessen for fronten, hvis vi vil ha en håndterlig og optimalisert kodebase. Når vi refactor CSS, vi Ryd opp og reorganiser vår eksisterende kode uten å legge til nye funksjoner eller fikse feil.
Refactoring hjelper forhindrer CSS-eksplosjon, forbedrer kodbarhet og gjenbrukbarhet, og gjør CSS slankere og raskere å utføre.
Refactoring er vanligvis nødvendig etter en stund, fordi selv prosjekter som startet med en konsis og organisert kodebase før eller senere begynner å miste sin klarhet; konsistens, foreldede regler og dupliserte kode deler vises; og vi begynner også å overstyre stiler og bruke flere og flere hacker og løsninger.
Den beste måten å holde vår CSS-kodebase vedlikeholdelig er å holde fast ved “refaktor tidlig, refactor ofte” tommelfingerregel. I dette innlegget vil vi se på noen tips om hvordan vi kan utføre en effektiv CSS refactoring-prosess.
1. Utfør en første revisjon
For å få et bedre bilde om hva vi trenger å refactor, er det best å Start med en omfattende revisjon for å se hva vi har for øyeblikket.
Det er mange flotte elektroniske verktøy som kan hjelpe oss med dette arbeidet. CSSDig er en kraftig Chrome-utvidelse som analyserer CSS på et nettsted, og utforsker svakheter, for eksempel for bestemte selektorer eller repeterende egenskaper.
Ubrukt CSS undersøker ubrukte CSS-regler, mens linting-verktøy, for eksempel CSS Lint, gjør det mulig å raskt finne kompabilitet, vedlikeholdsevne og andre problemer.
Det er også viktig å manuelt granske koden under den første revisjonen, da mange problemer på arkitektonisk nivå kun kan bli fanget på denne måten.
2. Opprett en styrbar plan
Refactoring arbeidskode er alltid en skremmende oppgave, men vi kan lindre smerten hvis vi lager en plan om hva vi trenger å gjøre, skille opp refactoringprosessen til håndterbare biter og lage en mulig tidsplan.
I CSS refactoring er det en viktig ting vi alltid trenger å ta hensyn til: Noen ting som vi refactor, f.eks. endring av velgerenavn, vil gjøre det nødvendig for å justere koden til de relevante HTML- og JavaScript-filene også.
Det er derfor en god ide å spore videre disse ekstra modifikasjonene vi må utføre, og bygge dem inn i vår refactoring tidsplan sammen med de primære, CSS-relaterte oppgavene.
3. Sporfremgang
Før du starter på refactoring, er det et viktig skritt for sikkerhetskopiere våre opprinnelige filer. Innføring av et versjonskontrollsystem, for eksempel Git eller Subversion, i arbeidsflyten vår, kan også forbedre refactoringprosessen vesentlig, siden vi har et register om de sekvensielle trinnene vi har tatt, og vi vil kunne gå tilbake til et tidligere stadium hvis vi vil gjenta ting.
4. Hold deg til en kodestilguide
En sammenhengende kodestilguide kan bemerkelsesverdig forbedre kodenes lesbarhet og vedlikeholdsevne, så før vi begynner å refactor er det viktig å sette opp en CSS koding stil guide.
De viktige tingene å bestemme seg på er:
- navngivningskonvensjoner
- formateringsregler
- erklæring rekkefølge
- enheter og verdier vi vil bruke
- kommentere regler
Hvis vi ikke ønsker å lage vår egen kodestilguide, kan vi også bruke noen andres, for eksempel ThinkUp's som kan finnes på Github.
Det er ikke nok til å bare introdusere en kodestilguide, vi må også hold deg til det når vi skriver om koden under refactoring, og Forvent det samme fra alle andre hvem jobber med vårt prosjekt.
5. Konfigurer en sammenhengende filstruktur
Etter at vi er klare med forberedelsene, er det første vi må gjøre, å sette opp en skikkelig CSS-filstruktur som tar hensyn til den cascading naturen til CSS.
Det er hovedsakelig avhengig av prosjektet hvor best å organisere våre filer, men det er noen universelle regler, for eksempel å bruke en egen normalize.css fil for CSS reset stiler, en separat global.css for globale stiler som brukes over hele prosjektet, og for å lagre tredjepartsbiblioteker i en egen mappe.
Hvis vi vil spille trygt med vår CSS filstruktur, er det også ferdige arkitekturer, som SMACSS eller ITCSS, som tilbyr effektive teknikker om hvordan å organisere CSS-filer på en skalerbar måte.
6. Bli kvitt ubrukte og dupliserte regler
Etter en stund begynner CSS-filer vanligvis å være overflødige i ubrukte regler som vi trenger å identifisere og rydde ut under refactoring. Det er mange elektroniske verktøy som gjør det mulig for oss undersøke disse foreldede reglene, og noen ganger også tillate oss å raskt dike dem.
Det mest kjente verktøyet for dette formålet er trolig UnCSS, en Node.js-modul som gjør det mulig å kvitte seg med ubrukte CSS-regler raskt, og det gir oss også sofistikerte konfigurasjonsalternativer som gjør det enkelt å finjustere rengjøringsprosessen.
Det er viktig å ta hensyn til at vi Ønsker ikke nødvendigvis å fjerne ubrukte regler fra alle CSS-filene vi har, for eksempel fra globale, tilbakestille eller tredje part stilark, så vi må utelukke dem mens du utfører rengjøringen.
Sammen med foreldede regler fører dupliserte regler også til overflødig kodeoppblokk og prestasjonsutfall. Vi kan fjerne dem ved hjelp av CSS Purge Node.js-modulen, men vi kan også jobbe med CSS-linjer for å søke etter dupliserte regler i våre CSS-filer.
7. Reduser spesifisitet
Specificiteten til en CSS-väljare er beregnet ut fra nummeret og typene av de indre selektorer det inneholder. CSS-spesifisitet er uttrykt som et 4-sifret tall som er lettest å forstå hvis vi sjekker ut denne visuelle CSS-spesifisitetskalkulatoren:
Den laveste spesifisiteten (0001) tilhører selektorer som bare målretter mot ett generelt HTML-element, for eksempel eller . Jo flere indre selektorer en sammensatte selektor inneholder, jo høyere er dens spesifisitet.
Visse selektorer, for eksempel id eller selektorer som kommer fra inline-stiler, har høyere prioriteter fordi de tilsidesetter stilene som tilhører flere generiske selektorer. For eksempel spesifisiteten til # ID1 velgeren er 0100.
I refactoring er målet å redusere spesifisiteten til selektorer (hold dem korte) så mye som mulig, som selektorer med høyere spesifisitet reduserer vesentlig gjenbrukbarhet av selektoren, og føre til en oppblåst kodebase.
De tre hovedtyper av high specificity selectors er:
- Kvalifiserte velgerne, som for eksempel
p.class1(definererptag er unødvendig her, da det gjør det umulig å bruke samme klasse med andre HTML-elementer) - Dypt nestede selektorer, som for eksempel
.klasse1 .class2 .class3 .class4 ... - IDer, som for eksempel
# ID1
Online verktøy, som CSSDig nevnt i trinn 1, kan brukes til å raskt finne disse high specificity selectors. Det kan også være nyttig å sette opp en regel i kodestilguiden om ting som maksimal nesting, eller en grense for bruk av id velgere.
8. Weed Out !viktig regler
CSS regler etterfulgt av !viktig erklæringen overstyrer vanlige stilregler. Ved hjelp av !viktig Regler før eller senere føre til usammenhengende kode. Det er ikke en tilfeldighet at de fleste linting-verktøy markerer dem som feil.
Når vi trenger å skrive CSS raskt, kan vi begynne å stole på dem selv på grunn av deres enkelhet.
Hovedproblemet med !viktig erklæringer er at hvis vi vil overstyre dem i fremtiden, må vi sette enda mer !viktig erklæringer i bruk, så det er best å luke dem ut hvor det er mulig under refactoring prosessen.
9. Ryd ut magiske tall og hardkodede verdier
Under vår daglige CSS-arbeidsflyt støter vi noen ganger i problemer vi ikke kan løse, og vi begynner å bruke såkalte magiske tall, verdier som fungerer av noen grunner, men vi forstår ikke hvorfor. Ta for eksempel følgende eksempel:
.klasse1 posisjon: absolutt; topp: 28px; venstre: 15,5%;
Hovedproblemet med magiske tall er at de er omstendelig, og de representerer “programmering ved permutasjon” antipattern. Under refactoringprosessen må vi fjerne disse vilkårlige reglene fra koden vår, og erstatte dem med mer rimelige løsninger, uansett hvor det er mulig.
Samme tommelfingerregel gjelder for hardkodede verdier også. Sannsynligvis er den hyppigste forekomsten av hardkodede verdier funnet i linjehøyde regler:
/ * dårlig, vi må legge til ekstra faste linjehøyderegler til barnelementene i .class1 * / .class1 font-size: 20px; linjehøyde: 24px; / * bra, den fleksible linjestyringsregelen kan også brukes av barnelementer * / .class1 font-size: 20px; linjehøyde: 1,2;
Hardkodede verdier gjør koden mindre fremtidssikker og mer stiv, så som en del av refactoring må vi grave dem opp, og erstatt dem med fleksible verdier.
10. Refactor Units og verdier
For å gjøre vedlikehold og feilsøking enklere i fremtiden, og for å unngå feil som kan skyldes bruk av forskjellige enheter, for eksempel em og px, samtidig må vi hold deg til sammenhengende regler om hvordan vi bruker relative og absolutte verdier.
Hvis vi brukte dem inkonsekvent i fortiden, må vi konvertere dem slik at de kan utgjøre et konsistent system
Hvis vi bruker for mange lignende farger på nettstedet vårt, kan det også være en klok ting å rasjonalisere fargeskjemaet ved å redusere antall farger vi bruker. (Her er et innlegg om hvordan du velger en nettsidefargeskjema på en praktisk måte.)
