Miten Refactor CSS - A-opas

CSS-refactoringin on oltava olennainen osa etukäteen kehitettävää työnkulkua, jos haluamme hallittavan ja optimoidun koodipohjan. Kun korjaamme CSS: n, me puhdista ja järjestele nykyinen koodi uudelleen ilman uusia ominaisuuksia tai vikoja.

Refactoring auttaa estää CSS-räjähdyksen, parantaa koodin luettavuutta ja uudelleenkäytettävyyttä, ja tekee CSS: n suloisemmaksi ja nopeammaksi.

Refaktorointia tarvitaan yleensä jonkin aikaa, sillä myös hankkeet, jotka aloitettiin ytimekkäästi ja järjestäytyneellä koodipohjalla, alkavat menettää selkeyden; johdonmukaisuus, vanhentuneet säännöt ja päällekkäiset koodiosat; ja alamme myös ohittaa tyylit ja työllistää yhä useampia hakkuita ja ratkaisuja.

Paras tapa pitää yllä CSS-koodipohjaa on pitää kiinni “refactor aikaisin, refactor usein” nyrkkisääntö. Tässä viestissä tarkastelemme joitakin vinkkejä siitä, miten voimme toteuttaa tehokkaan CSS-korjausprosessin.

1. Suorita ensimmäinen tarkastus

Paremman kuvan saamiseksi siitä, mitä meidän on palautettava, on parasta aloittaa kattava tarkastus, jotta näet, mitä meillä on tällä hetkellä.

On olemassa monia hyviä online-työkaluja, jotka voivat auttaa meitä tässä pyrkimyksessä. CSSDig on tehokas Chrome-laajennus, joka analysoi verkkosivuston CSS: n ja tutkii sen heikkoudet, kuten liian spesifiset valitsimet tai toistuvat ominaisuudet.

Käyttämätön CSS tutkii käyttämättömiä CSS-sääntöjä, kun taas nukkaustyökalut, kuten CSS Lint, mahdollistavat nopeasti saatavuuden, ylläpidettävyyden ja muiden ongelmien löytämisen.

On myös tärkeää tarkastaa koodi manuaalisesti alkuperäisen tarkastuksen aikana, sillä monet arkkitehtuurin ongelmat voidaan tarttua vain tällä tavalla.

2. Määritä hallittava suunnitelma

Työkoodin refaktorointi on aina pelottava tehtävä, mutta voimme helpottaa kipua, jos luomme suunnitelman siitä, mitä meidän on tehtävä, leikattava refaktorointiprosessi hallittaviin paloihin ja toteutettava toteutettavissa oleva aikataulu.

CSS-korjauksessa on ratkaiseva asia, jota meidän on aina otettava huomioon: jotkut asiat, joita me korjaamme, esim. valintanimien muuttaminen tekee sen tarvittavat HTML- ja JavaScript-tiedostot yhtä hyvin.

Siksi on hyvä ajatus jäljitä nämä muutokset, jotka meidän on suoritettava, ja rakentaa ne refactoring-aikataulumme yhdessä CSS: ään liittyvien ensisijaisten tehtävien kanssa.

3. Seuraa edistymistä

Ennen kuin aloitat korjauksen, se on tärkeä askel varmuuskopioimme alkuperäiset tiedostot. Versioiden hallintajärjestelmän, kuten Gitin tai Subversionin, käyttöönotto työnkulkuun voi myös parantaa merkittävästi refactoring-prosessia, koska meillä on rekisteri ottamistasi vaiheista ja me voi palata edelliseen vaiheeseen, jos haluamme uudistaa asioita.

4. Pidä kiinni koodaustyylioppaasta

Yhtenäinen koodaustyyliopas voi parantaa huomattavasti koodin luettavuutta ja ylläpitokelpoisuutta, joten ennen kuin aloitamme refactorin, se on välttämätöntä määritä CSS-koodaustyyli-opas.

Tärkeitä päätettäviä asioita ovat:

• nimityskäytäntöjä
• muotoilusäännöt
• ilmoitus
• yksiköt ja arvot, joita haluamme käyttää
• kommentointisäännöt

Jos emme halua luoda omaa koodaustyyliä, voimme myös käyttää jonkun muun, kuten ThinkUp: in, joka löytyy Githubista.

Ei riitä, että vain esitellään koodaustyyliopas, meidän on myös kiinni siitä, kun kirjoitamme koodin uudelleen korjauksen aikana ja odottaa samaa kaikilta muilta joka työskentelee projektissamme.

5. Määritä yhtenäinen tiedostorakenne

Kun olemme valmiita valmisteluihin, meidän on ensin luotava oikea CSS-tiedostorakenne, joka kiinnittää huomiota CSS: n asteittaiseen luonteeseen.

Se riippuu pääasiassa projektista, miten tiedostot voidaan järjestää parhaiten, mutta on olemassa joitakin yleisiä sääntöjä, kuten erillisen käytön normalize.css CSS-reset-tyylitiedosto, erillinen global.css globaaleille tyyleille, joita käytetään koko projektissa, ja tallentaa kolmannen osapuolen kirjastot erilliseen kansioon.

Jos haluamme pelata turvallisesti CSS-tiedostorakenteessamme, on myös valmiita arkkitehtuureja, kuten SMACSS tai ITCSS, jotka tarjoavat tehokkaita tekniikoita miten järjestää CSS-tiedostoja skaalattavalla tavalla.

6. Päästä eroon käyttämättömistä ja päällekkäisistä säännöistä

Hetken kuluttua CSS-tiedostot alkavat yleensä hyödyntää käyttämättömiä sääntöjä, jotka meidän on tunnistettava ja puhdistettava uudelleenrakennuksen aikana. On olemassa monia online-työkaluja, joiden avulla voimme tutkia näitä vanhentuneita sääntöjä, ja joskus myös sallimme niiden ojittamisen nopeasti.

Tunnetuin työkalu tähän tarkoitukseen on luultavasti UncSS, Node.js-moduuli, jonka avulla on mahdollista päästä eroon käyttämättömistä CSS-säännöistä nopeasti, ja se tarjoaa myös hienostuneita asetusvaihtoehtoja, joiden avulla on helppo hienosäätää puhdistusprosessia.

On tärkeää ottaa huomioon, että me eivät välttämättä halua poistaa käyttämättömiä sääntöjä kaikki CSS-tiedostoja meillä on, esimerkiksi globaaleista, nollaus- tai kolmannen osapuolen tyylisivuista, joten meidän täytyy sulkea ne puhdistuksen aikana.

Vanhojen sääntöjen ohella päällekkäiset säännöt johtavat myös tarpeettomaan koodinpuristukseen ja suorituskyvyn menetykseen. Voimme poistaa ne käyttämällä CSS Purge Node.js -moduulia, mutta voimme myös työskennellä CSS-linters, jotta etsitään päällekkäisiä sääntöjä CSS-tiedostoissamme.

7. Vähennä spesifisyyttä

CSS-valitsimen spesifisyys lasketaan sen sisältämien sisäisten valintalaitteiden lukumäärästä ja tyypeistä. CSS-spesifisyys ilmaistaan ​​nelinumeroinen luku, joka on helpoin ymmärtää, jos tarkastamme tämän visuaalisen CSS-spesifisyyden laskimen:

Pienin spesifisyys (0001) kuuluu valitsijoihin, jotka kohdistavat vain yhden yleisen HTML-elementin, kuten

tai

. Mitä enemmän sisäisiä valintalaitteita yhdistelmävalitsin sisältää, sitä korkeampi sen spesifisyys on.

Tietyt valitsimet, kuten id tai inline-tyylistä valittavista valinnoista on korkeampia prioriteetteja, koska ne ohittavat yleisempiin valikoimiin kuuluvat tyylit. Esimerkiksi. \ T # ID1 valitsin on 0100.

Refaktoroinnissa tavoitteena on vähentää selektorien spesifisyyttä (pitää ne lyhyinä) niin paljon kuin mahdollista korkeamman spesifisyyden omaavat valintalaitteet vähentävät merkittävästi valintakäytön käyttökelpoisuutta, ja johtaa paisutettuun koodipohjaan.

Kolme suurta spesifisyysvalitsinta tyyppiä ovat:

1. Hyväksytyt valitsimet, kuten p.class1 (määritellään p merkintä on tarpeeton tässä, koska se tekee mahdottomaksi käyttää samaa luokkaa muiden HTML-elementtien kanssa)
2. Syvästi sisäkkäiset valitsimet, kuten .class1. class2 .class3 .class4…
3. tunnukset, kuten # ID1

Verkkotyökaluja, kuten vaiheessa 1 mainittua CSSDigiä, voidaan käyttää nopeasti näiden korkean spesifisyyden valitsimien löytämiseen. Voi myös olla hyödyllistä määrittää sääntö koodaustyylioppaassa asioista, kuten pesimisen enimmäistasosta tai käyttörajoituksesta id valitsimet.

8. Weed Out !tärkeä säännöt

CSS-säännöt, joita seuraa !tärkeä lausunto ohittaa tavallisen tyylin säännöt. käyttämällä !tärkeä sääntöjä ennemmin tai myöhemmin johtaa epäyhtenäiseen koodiin. Ei ole sattumaa, että useimmat nukkaustyökalut merkitsevät ne virheiksi.

Kun meidän täytyy kirjoittaa CSS nopeasti, voimme alkaa luottaa niihin, vaikka niiden yksinkertaisuus.

Suurin ongelma !tärkeä Jos haluamme ohittaa ne tulevaisuudessa, meidän on annettava vielä enemmän !tärkeä käytössä olevat ilmoitukset, joten on parasta rikkoa ne aina, kun se on mahdollista refaktorointiprosessin aikana.

9. Puhdista Magic-numerot ja kovat koodatut arvot

Päivittäisen CSS-työnkulun aikana törmäämme joskus ongelmiin, joita emme voi ratkaista, ja alamme käyttää niin sanottuja maagisia numeroita, arvoja, jotka toimivat jostain syystä, mutta emme ymmärrä miksi. Ota esimerkiksi seuraava esimerkki:

 .class1 sijainti: absoluuttinen; alkuun: 28px; vasen: 15,5%; 

Maagisten numeroiden suurin ongelma on se, että ne ovat seikkaperäinen, ja he ilmentävät “ohjelmointi permutaation avulla” antisuunnittelumalli. Refactoring-prosessin aikana meidän on poistettava nämä mielivaltaiset säännöt koodistamme ja korvattava ne kohtuullisemmilla ratkaisuilla aina, kun se on mahdollista.

Sama nyrkkisääntö koskee kovakoodattuja arvoja yhtä hyvin. Todennäköisesti kovin koodattujen arvojen yleisin esiintyminen löytyy rivikorkeussäännöistä:

 / * huono, meidän on lisättävä ylimääräisiä kiinteän linjan korkeussääntöjä .class1 * / .class1 font-size: 20px; linjan korkeus: 24px;  / * hyvä, joustavat rivikorkeussäännöt voidaan käyttää turvallisesti myös lapsielementeissä * / .class1 font-size: 20px; linjan korkeus: 1.2; 

Koodaamattomat arvot tekevät koodistamme vähemmän tulevaisuuden ja jäykempiä, joten osana refaktorointia meidän on kaivettava ne ja korvata ne joustavilla arvoilla.

10. Refactor-yksiköt ja arvot

Jotta huolto ja virheenkorjaus olisi helpompaa tulevaisuudessa ja jotta vältettäisiin eri yksiköiden, kuten em ja px, samanaikaisesti meidän täytyy noudattaa yhtenäisiä sääntöjä siitä, miten käytämme suhteellisia ja absoluuttisia arvoja.

Jos käytimme niitä epäjohdonmukaisesti menneisyydessä, meidän on muutettava ne niin, että ne voivat muodostaa suppean järjestelmän

Jos käytämme sivustollamme liian monia samanlaisia ​​värejä, se voi olla myös viisasta järkeistää värimaailmaa vähentämällä käyttämiemme värien määrää. (Tässä on viesti siitä, miten verkkosivustojen värimallia voidaan valita käytännössä.)