Sådan Refactor CSS - En Guide
CSS refactoring skal være en væsentlig del af front-end udviklings-workflow, hvis vi ønsker at have en håndterbar og optimeret kodebase. Når vi refactor CSS, vi rydde op og omorganisere vores eksisterende kode uden at tilføje nye funktioner eller fastsætte fejl.
Refactoring hjælper forhindrer CSS-eksplosion, forbedrer kodens læsbarhed og genbrugelighed, og gør CSS slankere og hurtigere at udføre.
Refactoring er normalt brug for efter et stykke tid, da selv projekter, der startede med en kortfattet og organiseret kodebase, snart eller senere begynder at miste deres klarhed; konsistens, forældede regler og duplikat kode dele vises; og vi begynder også at tilsidesætte stilarter og ansætte flere og flere hacks og løsninger.
Den bedste måde at holde vores CSS kode base vedligeholdes er at holde fast ved “refaktor tidligt, refactor ofte” tommelfingerregel. I dette indlæg vil vi se på nogle tip om, hvordan vi kan udføre en effektiv CSS refactoring proces.
1. Gennemfør en oprindelig revision
For at få et bedre billede om, hvad vi har brug for at refactor, er det bedst at Start med en omfattende revision for at se, hvad vi har i øjeblikket.
Der er mange gode onlineværktøjer, der kan hjælpe os i denne indsats. CSSDig er en kraftig Chrome-udvidelse, der analyserer CSS på et websted, og undersøger dets svagheder, som for specifikke selektorer eller gentagne egenskaber.
Ubrugt CSS undersøger ubrugte CSS-regler, mens linting-værktøjer, som f.eks. CSS Lint, gør det muligt hurtigt at finde kompabilitet, vedligeholdelsesevne og andre problemer.
Det er også vigtigt at manuelt gennemgå koden under den oprindelige revision, da mange problemer på arkitektonisk niveau kun kan fanges på denne måde.
2. Opsæt en administrerbar plan
Refactoring arbejdskode er altid en skræmmende opgave, men vi kan lette smerten, hvis vi laver en plan om, hvad vi skal gøre, skære refactoringprocessen til håndterbare klumper og lav en gennemførlig tidsplan.
I CSS refactoring er der en vigtig ting, som vi altid har brug for, i betragtning: nogle ting, som vi refactor, f.eks. ændrer vælger navne, vil gøre det nødvendigt at justere koden for de relevante HTML- og JavaScript-filer såvel.
Det er derfor en god ide at spore frem disse yderligere ændringer, vi skal udføre, og bygge dem ind i vores refactoring tidsplan sammen med de primære, CSS-relaterede opgaver.
3. Sporing fremskridt
Før det går i gang med refactoring, er det et vigtigt skridt til sikkerhedskopiere vores oprindelige filer. Hvis vi introducerer et versionsstyringssystem, som Git eller Subversion, ind i vores workflow, kan vi også forbedre refactoringprocessen betydeligt, da vi har et register over de efterfølgende trin, vi har taget, og vi vil være i stand til at vende tilbage til et tidligere stadium, hvis vi vil genoprette ting.
4. Hold dig til en kodestilguide
En sammenhængende kodestilguide kan bemærkelsesværdigt forbedre kodens læsbarhed og vedligeholdelighed, så inden vi begynder at refactor er det vigtigt at oprette en CSS kodning stil guide.
De vigtige ting at afgøre er:
- navngivningskonventioner
- formateringsregler
- erklæring rækkefølge
- enheder og værdier, vi vil bruge
- kommenteringsregler
Hvis vi ikke ønsker at oprette vores egen kodestilguide, kan vi også bruge en andens, f.eks. ThinkUp's, som kan findes på Github.
Det er ikke nok, men bare at introducere en kodestilguide, vi skal også holde fast ved det, når vi omskriver koden under refactoring og Forvent det samme fra alle andre hvem arbejder på vores projekt.
5. Opret en sammenhængende filstruktur
Når vi er klar med forberedelserne, er det første, vi skal gøre, at oprette en ordentlig CSS-filstruktur, der lægger vægt på CSS-cascading-karakteren.
Det afhænger hovedsageligt af projektet, hvordan man bedst kan organisere vores filer, men der er nogle universelle regler, som f.eks. At bruge en separat normalize.css fil til CSS reset stilarter, en separat global.css til globale stilarter, der bruges over hele projektet, og at gemme tredjepartsbiblioteker i en separat mappe.
Hvis vi ønsker at spille sikkert med vores CSS filstruktur, er der også færdige arkitekturer, såsom SMACSS eller ITCSS, der tilbyder effektive teknikker om hvordan man organiserer CSS-filer på en skalerbar måde.
6. slippe af med ubrugte og duplikatregler
Efter et stykke tid begynder CSS-filer normalt at være overflod i ubrugte regler, som vi skal identificere og rense ud under refactoring. Der er mange online værktøjer, der gør det muligt for os undersøge disse forældede regler, og til tider tillader os også hurtigt at grøfte dem.
Det mest kendte værktøj til dette formål er nok UnCSS, et Node.js-modul, der gør det muligt hurtigt at slippe af med ubrugte CSS-regler, og det giver os også avancerede konfigurationsmuligheder, der gør det nemt at finjustere rengøringsprocessen.
Det er vigtigt at tage højde for, at vi Ønsker ikke nødvendigvis at fjerne ubrugte regler fra alle de CSS-filer, vi har, for eksempel fra globale, nulstillede eller 3rd party stylesheets, så vi skal udelukke dem mens du udfører rengøringen.
Sammen med forældede regler fører også dobbelte regler til overflødig kodeopblussen og præstationstab. Vi kan fjerne dem ved at bruge CSS Purge Node.js modulet, men vi kan også arbejde med CSS-lindere for at søge efter duplikatregler i vores CSS-filer.
7. Reducer specificitet
Specificiteten af en CSS-vælger beregnes ud fra antallet og typerne af de indre selektorer, den indeholder. CSS-specificitet udtrykkes som et 4-cifret tal, der er nemmest at forstå, hvis vi tjekker denne visuelle CSS-specificitetsregnemaskine:
Den laveste specificitet (0001) tilhører selektorer, der kun målretter mod et generelt HTML-element, f.eks eller . Jo flere indre selektorer en sammensat selector indeholder, desto højere er dens specificitet.
Visse vælgere, f.eks id eller selektorer, der kommer fra inline-stilarter, har højere prioriteter, fordi de tilsidesætter de stilarter, der tilhører flere generiske selektorer. For eksempel specificiteten af # id1 vælgeren er 0100.
I refactoring er målet at reducere selectors specificitet (hold dem korte) så meget som muligt selektorer med højere specificitet reducerer markant genanvendelighed betydeligt, og føre til en oppustet kodebase.
De tre hovedtyper af high specificity selectors er:
- Kvalificerede selektorer, såsom
p.class1(definererptag er unødvendigt her, da det gør det umuligt at bruge samme klasse med andre HTML-elementer) - Dybt indlejrede selektorer, såsom
.klasse1 .class2 .class3 .class4 ... - id'er, såsom
# id1
Onlineværktøjer, som CSSDig nævnt i Trin 1, kan bruges til hurtigt at finde disse high specificity selectors. Det kan også være nyttigt at oprette en regel i kodestilguiden om ting som det maksimale nestniveau eller en grænse for brugen id selektorer.
8. Weed Out !vigtig Regler
CSS regler efterfulgt af !vigtig erklæringen tilsidesætter regelmæssige stilregler. Ved brug af !vigtig regler før eller senere føre til usammenhængende kode. Det er ikke tilfældigt, at de fleste lintende værktøjer markerer dem som fejl.
Når vi skal skrive CSS hurtigt, kan vi begynde at stole på dem selv på grund af deres enkelhed.
Det største problem med !vigtig erklæringer er, at hvis vi vil tilsidesætte dem i fremtiden, skal vi sætte endnu mere !vigtig erklæringer i brug, så det er bedst at udrydde dem, hvor det er muligt under refactoring processen.
9. Rengør Magic Numbers og hardcoded værdier
Under vores daglige CSS-arbejdsgang støder vi nogle gange i problemer, vi ikke kan løse, og vi begynder at bruge såkaldte magiske tal, værdier, der virker af nogle grunde, men vi forstår ikke hvorfor. F.eks. Tag følgende eksempel:
.klasse1 position: absolut; top: 28px; venstre: 15,5%;
Det største problem med magiske tal er, at de er indicier, og de belyser den “programmering ved permutation” antipattern. Under refactoring processen skal vi fjerne disse vilkårlig regler fra vores kode og erstatte dem med mere rimelige løsninger, hvor det er muligt.
Den samme tommelfingerregel gælder for hardkodede værdier såvel. Sandsynligvis er den hyppigst forekommende forekomst af hardkodede værdier fundet i linjehøjde regler:
/ * dårlig, vi skal tilføje ekstra faste linjehøjder regler til barnets elementer af .class1 * / .class1 font-size: 20px; linjehøjde: 24px; / * god, den fleksible linjestyrke regel kan også bruges af børneelementer * / .class1 font-size: 20px; linie højde: 1,2;
Hardkodede værdier gør vores kode mindre fremtidssikker og mere stiv, så som en del af refactoring skal vi grave dem op, og erstatte dem med fleksible værdier.
10. Refactor Units and Values
For at gøre vedligeholdelse og fejlfinding lettere i fremtiden, og for at undgå fejl, der kan skyldes brug af forskellige enheder, f.eks em og px, samtidig skal vi holde fast i sammenhængende regler om, hvordan vi bruger relative og absolutte værdier.
Hvis vi tidligere brugte dem uoverensstemmende, skal vi konvertere dem, så de kan udgøre et kortfattet system
Hvis vi bruger for mange lignende farver på vores hjemmeside, kan det også være en klog ting at rationalisere farveskemaet ved at reducere antallet af farver vi anvender. (Her er et indlæg om, hvordan man vælger et website farveskema på en praktisk måde.)
