Hoe een refactor CSS - een gids

CSS-refactoring moet een essentieel onderdeel zijn van de front-end ontwikkelingsworkflow, als we een beheersbare en geoptimaliseerde codebasis willen hebben. Wanneer we CSS refactoren, wij opschonen en reorganiseren van onze bestaande code zonder nieuwe functies toe te voegen of bugs te verhelpen.

Refactoring helpt voorkomen van CSS-explosie, verbetert code leesbaarheid en herbruikbaarheid, en maakt CSS slanker en sneller uit te voeren.

Refactoring is meestal na een tijdje nodig, omdat zelfs projecten die begonnen met een beknopte en georganiseerde codebasis, vroeg of laat hun helderheid beginnen te verliezen; consistentie, verouderde regels en dubbele codedelen verschijnen; en we beginnen ook stijlen te overschrijven en steeds meer hacks en workarounds in te zetten.

De beste manier om onze CSS-codebasis onderhoudenbaar te houden, is vasthouden aan de “refactor vroeg, refactor vaak” vuistregel. In deze post zullen we enkele tips bekijken over hoe we een effectief CSS refactoring-proces kunnen uitvoeren.

1. Voer een eerste audit uit

Om een ​​beter beeld te hebben van wat we nodig hebben om te refactoren, is dit het beste begin met een uitgebreide audit om te zien wat we momenteel hebben.

Er zijn veel geweldige online tools die ons kunnen helpen bij dit streven. CSSDig is een krachtige Chrome-extensie die de CSS van een website analyseert en de zwakke punten ervan onderzoekt, zoals te specifieke selectors of herhalende eigenschappen.

Ongebruikte CSS onderzoekt ongebruikte CSS-regels, terwijl linting-tools, zoals CSS Lint, het mogelijk maken om snel compatibiliteit, onderhoudbaarheid en andere problemen te vinden.

Het is ook belangrijk om de code tijdens de eerste audit handmatig te controleren, omdat veel problemen op architectonisch niveau alleen op deze manier kunnen worden opgevangen.

2. Stel een beheersbaar plan op

Werkcode herformuleren is altijd een moeilijke taak, maar we kunnen de pijn verlichten als we een plan maken over wat we moeten doen, het refactoringproces versnipperen tot hanteerbare brokken en een haalbaar schema maken.

Bij CSS-refactoring is er een cruciaal ding waar we altijd rekening mee moeten houden: sommige dingen die we refacteren, bijvoorbeeld veranderende selector namen, zal het redden nodig om de code van de relevante HTML- en JavaScript-bestanden aan te passen ook.

Het is daarom een ​​goed idee om traceer deze aanvullende aanpassingen die we moeten uitvoeren, en bouw ze op in ons refactorschema samen met de primaire, CSS-gerelateerde taken.

3. Volg voortgang

Voordat we beginnen met refactoring, is het een essentiële stap om maak een back-up van onze initiële bestanden. Het introduceren van een versiebeheersysteem, zoals Git of Subversion, in onze workflow kan het refactoring-proces aanzienlijk verbeteren, omdat we een register hebben over de opeenvolgende stappen die we hebben genomen, en we kan terugkeren naar een vorige fase als we dingen opnieuw willen doen.

4. Blijf bij een coderingsstijlgids

Een coherente coderingsstijlgids kan opmerkelijk de codele leesbaarheid en onderhoudbaarheid verbeteren, dus voordat we beginnen met refactoren is het essentieel om dit te doen stel een CSS-coderingsstijlgids op.

De belangrijke dingen om te beslissen zijn:

• naamgevingsconventies
• opmaakregels
• declaratie
• eenheden en waarden die we willen gebruiken
• commentaarregels

Als we onze eigen codeerstijlgids niet willen maken, kunnen we ook die van iemand anders gebruiken, zoals ThinkUp's die te vinden zijn op Github.

Het is echter niet genoeg om een ​​gids voor codeerstijlen te introduceren, we moeten dat ook blijf erbij als we de code herschrijven tijdens het refactoring, en verwacht hetzelfde van iedereen wie werkt aan ons project.

5. Stel een samenhangende bestandsstructuur in

Nadat we klaar zijn met de voorbereidingen, is het eerste wat we moeten doen om een ​​juiste CSS-bestandsstructuur in te stellen die aandacht besteedt aan de cascadering van CSS.

Het hangt voornamelijk af van het project hoe onze bestanden het best kunnen worden georganiseerd, maar er zijn enkele universele regels, zoals het gebruik van een afzonderlijke normalize.css bestand voor CSS-resetstijlen, een apart global.css voor algemene stijlen die in het hele project worden gebruikt en om bibliotheken van derden in een aparte map op te slaan.

Als we veilig willen spelen met onze CSS-bestandsstructuur, zijn er ook kant-en-klare architecturen, zoals SMACSS of ITCSS, die effectieve technieken bieden over hoe CSS-bestanden op een schaalbare manier te ordenen.

6. Weg met ongebruikte en dubbele regels

Na een tijdje beginnen CSS-bestanden meestal vol te lopen met ongebruikte regels die we moeten identificeren en opschonen tijdens refactoring. Er zijn veel online tools die ons in staat stellen om onderzoek deze verouderde regels, en laten we ons soms ook snel ontdoen van hen.

De bekendste tool voor dit doel is waarschijnlijk UnCSS, een Node.js-module die het mogelijk maakt snel van ongebruikte CSS-regels af te komen, en het biedt ons ook geavanceerde configuratie-opties die het gemakkelijk maken om het schoonmaakproces aan te passen.

Het is belangrijk om er rekening mee te houden dat wij wil niet noodzakelijk ongebruikte regels verwijderen van allemaal de CSS-bestanden die we hebben, bijvoorbeeld van de stylesheets voor globaal, opnieuw instellen of derden, dus dat moeten we doen sluit ze uit tijdens het uitvoeren van de reiniging.

Samen met verouderde regels leiden dubbele regels ook tot overtollige code-uitval en prestatieverlies. We kunnen ze verwijderen met behulp van de CSS Purge Node.js-module, maar we kunnen ook werken CSS-linters om te zoeken naar dubbele regels in onze CSS-bestanden.

7. Specificiteit verminderen

De specificiteit van een CSS-selector wordt berekend op basis van het aantal en de typen binnenste selecteurs die het bevat. CSS-specificiteit wordt uitgedrukt als een 4-cijferig getal dat het gemakkelijkst te begrijpen is als we deze visuele CSS-specificatiecalculator bekijken:

De laagste specificiteit (0001) behoort tot selectors die alleen één algemeen HTML-element targeten, zoals

of

. Hoe meer innerlijke selecteurs een samengestelde selector bevat, des te hoger de specificiteit ervan.

Bepaalde selectors, zoals ID kaart of selectors die afkomstig zijn van inline-stijlen, hebben hogere prioriteiten omdat ze de stijlen negeren die behoren tot meer generieke selectors. Bijvoorbeeld de specificiteit van de # id1 selector is 0100.

Bij refactoring is het doel om de specificiteit van selectors (zoveel mogelijk kort) te verminderen, zoals het mogelijk is selectors met hogere specificiteit verminderen de selector herbruikbaarheid aanzienlijk, en leiden tot een opgeblazen codebasis.

De 3 belangrijkste types van hoge specificiteitselectoren zijn:

1. Gekwalificeerde selectors, zoals p.class1 (het definiëren van de p tag is hier niet nodig, omdat het onmogelijk is om dezelfde klasse te gebruiken met andere HTML-elementen)
2. Diep genestelde selectors, zoals .class1 .class2 .class3 .class4 ...
3. IDs, zoals # id1

Online tools, zoals CSSDig genoemd in stap 1, kunnen worden gebruikt om snel deze high specificity selectors te vinden. Het kan ook handig zijn om een ​​regel in de coderingsstijlgids op te stellen over zaken als het maximale nesteniveau of een limiet voor het gebruik van ID kaart selectors.

8. Weed uit !belangrijk Reglement

CSS-regels gevolgd door de !belangrijk verklaring overschrijft reguliere stijlregels. Gebruik makend van !belangrijk regels vroeg of laat leiden tot incoherente code. Het is geen toeval dat de meeste plukkende gereedschappen ze markeren als fouten.

Wanneer we CSS snel moeten schrijven, kunnen we daarop misschien gaan vertrouwen vanwege hun eenvoud.

Het grootste probleem met !belangrijk verklaringen is dat als we ze in de toekomst willen negeren, we nog meer moeten doen !belangrijk aangiften in gebruik, dus het is het beste om ze uit te wieden waar het mogelijk is tijdens het refactoring-proces.

9. Magic Numbers en Hard Coded Values ​​opruimen

Tijdens onze dagelijkse CSS-workflow botsen we soms op problemen die we niet kunnen oplossen en beginnen we met het gebruik van zogenaamde magische nummers, waarden die om een ​​aantal redenen werken, maar we begrijpen niet waarom. Neem bijvoorbeeld het volgende voorbeeld:

 .class1 positie: absoluut; top: 28px; links: 15,5%; 

Het grootste probleem met magische getallen is dat ze dat wel zijn bijkomstig, en zij belichamen de “programmeren door middel van permutatie” antipattern. Tijdens het refactoring-proces moeten we deze willekeurige regels uit onze code verwijderen en deze vervangen door redelijker mogelijke oplossingen, waar dat mogelijk is.

Dezelfde vuistregel is van toepassing hardgecodeerde waarden ook. Waarschijnlijk is het meest voorkomende voorkomen van hardgecodeerde waarden te vinden in regelhoogte-regels:

 / * slecht, we moeten extra regels voor vaste lijnhoogte toevoegen aan de onderliggende elementen van .class1 * / .class1 font-size: 20px; regelhoogte: 24 px;  / * goed, de flexibele lijnhoogte-regel kan ook veilig worden gebruikt door onderliggende elementen * / .class1 font-size: 20px; regelhoogte: 1,2; 

Hard gecodeerde waarden maken onze code minder toekomstbestendig en meer rigide, dus als onderdeel van refactoring moeten we ze opgraven, en vervang ze door flexibele waarden.

10. Refactor-eenheden en -waarden

Om onderhoud en debugging in de toekomst eenvoudiger te maken en om storingen te voorkomen die kunnen voortkomen uit het gebruik van verschillende eenheden, zoals em en px, tegelijkertijd moeten we dat doen vasthouden aan samenhangende regels over hoe we relatieve en absolute waarden gebruiken.

Als we ze in het verleden inconsistent hebben gebruikt, moeten we ze omzetten zodat ze een beknopt systeem kunnen vormen

Als we op onze site te veel vergelijkbare kleuren gebruiken, kan het ook verstandig zijn om dit te doen rationaliseer het kleurenschema door het aantal kleuren dat we gebruiken te verminderen. (Hier is een bericht over hoe u op een praktische manier een websitekleurenschema kunt kiezen.)