CSS kaskados sluoksnių integravimas į esamą projektą

Puikią apžvalgą visada galite rasti Stephenie Eckles straipsnyje „Darbo su CSS kaskados sluoksniais pradžia“. Bet pakalbėkime apie kaskados sluoksnių integravimo į realų kodą patirtį – gerus, blogus ir „spagečių“ kodo aspektus.

Galėjome sukurti pavyzdinį projektą klasikinei pamokai, bet ne, realiame pasaulyje viskas veikia ne taip. Norime išsitepti rankas, tarsi paveldėję kodą su veikiančiais stiliais, kurių veikimo principo niekas nežino.

Rasti projektų be kaskados sluoksnių buvo lengva. Sunkiau buvo rasti tokį, kuris būtų pakankamai netvarkingas, kad turėtų specifiškumo ir organizavimo problemų, bet pakankamai platus, kad iliustruotų skirtingas kaskados sluoksnių integravimo dalis.

Ponios ir ponai, pristatome jums šią „Discord“ boto svetainę, kurią sukūrė Drishtant Ghosh. Esame labai dėkingi Drishtantui, kad leido mums panaudoti jo darbą kaip pavyzdį. Šis projektas yra tipinis nukreipimo puslapis su naršymo juosta, pagrindine sekcija, keliais mygtukais ir mobiliuoju meniu.

„Discord Bot“ pradinis puslapis, kuriame yra apvalus logotipas, išcentruotas virš antraštės, tekstas, tada trys mygtukai eilėje.

Matote, kaip iš išorės viskas atrodo puikiai. Tačiau viskas pasidaro įdomu, kai pažvelgiame į CSS stilius po gaubtu.

Projekto supratimas

Prieš pradedant mėtytis @layer taisyklėmis, gerai susipažinkime su tuo, su kuo dirbame. Nuklonovome „GitHub“ saugyklą, ir kadangi mūsų tikslas yra dirbti su CSS kaskados sluoksniais, sutelksime dėmesį tik į pagrindinį puslapį, kurį sudaro trys failai: index.html, index.css ir index.js.

Pastaba: Neįtraukėme kitų šio projekto puslapių, nes tai padarytų šią pamoką per daug išsamią. Tačiau galite pertvarkyti kitus puslapius kaip eksperimentą.

index.css failas turi daugiau nei 450 kodo eilučių, ir peržvelgus jį, iškart matome kelis pavojaus ženklus:

Daug kodo pasikartojimo, kai tie patys selektoriai nurodo tą patį HTML elementą.
Yra nemažai #id selektorių, dėl kurių galima ginčytis, ar jie apskritai turėtų būti naudojami CSS (ir mes esame vieni iš tų žmonių).
#botLogo apibrėžtas du kartus, o tarp apibrėžimų yra daugiau nei 70 eilučių.
Raktinis žodis !important gausiai naudojamas visame kode.

Ir vis dėlto svetainė veikia. Čia nėra nieko „techniškai“ blogo, ir tai dar viena priežastis, kodėl CSS yra didelis, gražus monstras – klaidos yra tylios!

Sluoksnių struktūros planavimas

Dabar kai kurie gali pagalvoti: „Ar negalėtume tiesiog perkelti visų stilių į vieną sluoksnį, pavyzdžiui, @layer legacy ir tuo viską baigti?“

Galėtumėte... bet nemanome, kad turėtumėte.

Pagalvokite: jei po legacy sluoksnio bus pridėta daugiau sluoksnių, jie turėtų perrašyti legacy sluoksnyje esančius stilius, nes sluoksnių specifiškumas organizuojamas pagal prioritetą, kur vėliau deklaruoti sluoksniai turi didesnį prioritetą.

/* new yra specifiškesnis */
@layer legacy, new;

/* legacy yra specifiškesnis */
@layer new, legacy;

‍Vis dėlto, turime prisiminti, kad esamuose svetainės stiliuose gausiai naudojamas !important raktinis žodis. O kai taip nutinka, kaskados sluoksnių tvarka apsiverčia. Taigi, nors sluoksniai apibrėžti taip:

@layer legacy, new;

…bet kurie stiliai su !important deklaracija staiga viską sumaišo. Šiuo atveju prioritetų tvarka tampa tokia:

!important stiliai legacy sluoksnyje (galingiausi),
!important stiliai new sluoksnyje,
Normalūs stiliai new sluoksnyje,
Normalūs stiliai legacy sluoksnyje (mažiausiai galingi).

Norėjome tai paaiškinti. Tęskime.

Žinome, kad kaskados sluoksniai valdo specifiškumą sukurdami aiškią tvarką, kur kiekvienas sluoksnis turi aiškią atsakomybę, o vėlesni sluoksniai visada laimi.

Taigi, nusprendėme viską suskirstyti į penkis atskirus sluoksnius:

reset: Naršyklės numatytųjų stilių atstatymai, pvz., box-sizing, margin ir padding.
base: Numatytieji HTML elementų stiliai, pvz., body, h1, p, a, įskaitant numatytąją tipografiką ir spalvas.
layout: Pagrindinės puslapio struktūros dalys, kontroliuojančios elementų padėtį.
components: Daugkartinio naudojimo vartotojo sąsajos segmentai, pvz., mygtukai, kortelės ir meniu.
utilities: Pavieniai pagalbiniai modifikatoriai, kurie daro tik vieną dalyką ir daro jį gerai.

Tai tik mūsų mėgstamas būdas skirstyti ir organizuoti stilius. Pavyzdžiui, Zell Liew turi kitokį keturių grupių rinkinį, kurį galima apibrėžti kaip sluoksnius.

Taip pat egzistuoja koncepcija viską suskirstyti dar smulkiau į posluoksnius:

@layer components {  
	/* posluoksniai */  
	@layer buttons, cards, menus;
}

/* arba taip: */
@layer components.buttons, components.cards,
components.menus;

‍Tai gali praversti, bet taip pat nenorime per daug abstrahuoti. Tai galėtų būti geresnė strategija projektui, kuris yra apibrėžtas gerai sukurta dizaino sistema.

Kitas dalykas, kurį galėtume panaudoti, yra nesluoksniuoti stiliai ir faktas, kad bet kokie stiliai, nesantys kaskados sluoksnyje, gauna aukščiausią prioritetą:

@layer legacy { a { color: red !important; } }
@layer reset { a { color: orange !important; } }
@layer base { a { color: yellow !important; } }
/* nesluoksniuotas */
a { color: green !important; } /* aukščiausias prioritetas */

Bet mums patinka idėja visus stilius laikyti organizuotus aiškiuose sluoksniuose, nes tai išlaiko viską moduliariška ir lengvai prižiūrima, bent jau šiame kontekste.

Pereikime prie kaskados sluoksnių pridėjimo į šį projektą.

Kaskados sluoksnių integravimas

Turime apibrėžti sluoksnių tvarką failo viršuje:

@layer reset, base, layout, components, utilities;

Tai leidžia lengvai suprasti, kuris sluoksnis turi viršenybę prieš kurį (jie gauna daugiau prioriteto iš kairės į dešinę), ir dabar galime galvoti sluoksnių atsakomybės, o ne selektoriaus svorio terminais. Toliau judėsime per stilių failą nuo viršaus iki apačios.

Pirmiausia pastebėjome, kad Poppins šriftas buvo importuotas tiek HTML, tiek CSS failuose, todėl pašalinome CSS importą ir palikome tą, kuris yra index.html – tai paprastai rekomenduojama greitesniam šriftų įkėlimui.

Toliau eina universaliojo selektoriaus (*) stiliai, kurie apima klasikinius atstatymo stilius, puikiai tinkančius @layer reset:

@layer reset {
  * {
    margin: 0;
    padding: 0;
    box-sizing: border-box;
  }
}

Atsikračius šito, kitas yra body selektorius. Dedame jį į @layer base, nes jame yra pagrindiniai projekto stiliai, tokie kaip fonai ir šriftai:

@layer base {
  body {
    background-image: url("bg.svg"); /* Pervadinta į bg.svg aiškumo dėlei */
    font-family: "Poppins", sans-serif;
    /* ... kiti stiliai */
  }
}

Mūsų požiūris yra toks, kad base sluoksnio stiliai paprastai turėtų paveikti visą dokumentą. Kol kas jokių puslapio lūžių ar panašiai.

ID keitimas klasėmis

Po body elemento selektoriaus eina puslapio įkėlimo elementas, apibrėžtas kaip ID selektorius, #loader.

Esame tvirtai įsitikinę, kad reikia kuo dažniau naudoti klasių selektorius, o ne ID selektorius. Tai išlaiko specifiškumą žemą pagal nutylėjimą, kas apsaugo nuo specifiškumo kovų ir padaro kodą daug lengviau prižiūrimą.

Taigi, nuėjome į index.html failą ir pertvarkėme elementus su id="loader" į class="loader". Proceso metu pamatėme kitą elementą su id="page" ir pakeitėme jį tuo pačiu metu.

Būdami index.html faile, pastebėjome kelis div elementus be uždarymo žymių. Stebėtina, kokios atlaidžios yra naršyklės. Bet kokiu atveju, sutvarkėme juos ir perkėlėme <script> žymę iš .heading elemento, kad ji būtų tiesioginis body vaikas. Neapsunkinkime savo scenarijų įkėlimo.

Dabar, kai suvienodinome specifiškumo žaidimo lauką perkeldami ID į klases, galime juos įdėti į components sluoksnį, nes įkėlimo elementas išties yra daugkartinio naudojimo komponentas:

@layer components {
  .loader {
    width: 100%;
    height: 100vh;
    /* ... */
  }
  .loader .loading {
    /* ... */
  }
  /* ... */
}

Animacijos

Toliau eina keyframes, ir tai buvo šiek tiek sudėtinga, bet galiausiai nusprendėme išskirti animacijas į atskirą naują penktą sluoksnį ir atnaujinome sluoksnių tvarką, kad jį įtrauktume:‍

@layer reset, base, layout, components, utilities, animations;

Bet kodėl animations dėti kaip paskutinį sluoksnį? Nes animacijos paprastai vykdomos paskutinės ir neturėtų būti paveiktos stilių konfliktų.

Ieškojome projekto stiliuose @keyframes ir sudėjome juos į naują sluoksnį:‍

@layer animations {
  @keyframes loading {
    /* ... */
  }
  @keyframes loading2 {
    /* ... */
  }
  @keyframes pageShow {
    /* ... */
  }
}

Tai suteikia aiškų skirtumą tarp statinių ir dinaminių stilių, kartu užtikrinant daugkartinį naudojimą.

Išdėstymai

#page selektorius turi tą pačią problemą kaip ir #id, ir kadangi anksčiau tai sutvarkėme HTML, galime jį pakeisti į .page ir įdėti į layout sluoksnį, nes jo pagrindinis tikslas yra kontroliuoti pradinį turinio matomumą:

@layer layout {
  .page {
    display: none;
  }
}

Individualios slinkties juostos

Kur dėti šias? Slinkties juostos yra globalūs elementai, kurie išlieka visoje svetainėje. Tai gali būti pilkoji zona, bet sakytume, kad tai puikiai tinka @layer base, nes tai yra globali, numatytoji funkcija.

@layer base {
  /* ... */
  ::-webkit-scrollbar {
    width: 8px;
  }
  ::-webkit-scrollbar-track {
    background: #0e0e0f;
  }
  ::-webkit-scrollbar-thumb {
    background: #5865f2;
    border-radius: 100px;
  }
  ::-webkit-scrollbar-thumb:hover {
    background: #202225;
  }
}

Taip pat pašalinome !important raktinius žodžius, kai juos aptikome.

Navigacija

nav elementas yra gana paprastas, nes tai yra pagrindinis struktūros konteineris, apibrėžiantis navigacijos juostos padėtį ir matmenis. Jis tikrai turėtų eiti į layout sluoksnį:

@layer layout {
  /* ... */
  nav {
    display: flex;
    height: 55px;
    width: 100%;
    padding: 0 50px; /* Consistent horizontal padding */
    /* ... */
  }
}

Logotipas

Turime tris stilių blokus, susijusius su logotipu: nav .logo, .logo img ir #botLogo. Šie pavadinimai yra pertekliniai ir galėtų pasinaudoti paveldėjimo komponentų daugkartiniu naudojimu.

Štai mūsų požiūris:

nav .logo yra per daug specifiškas, nes logotipą galima naudoti ir kitose vietose. Nuleidome nav, kad selektorius būtų tiesiog .logo. Taip pat ten buvo !important raktinis žodis, todėl jį pašalinome.
Atnaujinome .logo į „Flexbox“ konteinerį, kad padėtų pozicionuoti .logo img, kuris anksčiau buvo nustatytas mažiau lanksčiu absoliučiu pozicionavimu.
#botLogo ID yra deklaruotas du kartus, todėl sujungėme dvi taisyklių aibes į vieną ir sumažinome jo specifiškumą, padarydami jį .botLogo klase. Ir, žinoma, atnaujinome HTML, pakeisdami ID klase.
.logo img selektorius tampa .botLogo, padarydami jį pagrindine klase visų logotipo egzempliorių stilizavimui.

Dabar mums liko štai kas:

/* initially .logo img */
.botLogo {
  border-radius: 50%;
  height: 40px;
  border: 2px solid #5865f2;
}

/* initially #botLogo */
.botLogo {
  border-radius: 50%;
  width: 180px;
  /* ... */
}

Skirtumas tas, kad vienas naudojamas navigacijoje, o kitas – pagrindinės sekcijos antraštėje. Galime transformuoti antrąjį .botLogo, šiek tiek padidindami specifiškumą su .heading .botLogo selektoriumi. Taip pat galime išvalyti visus pasikartojančius stilius.

Įdėkime visą kodą į components sluoksnį, nes sėkmingai pavertėme logotipą daugkartinio naudojimo komponentu:

@layer components {
  /* ... */
  .logo {
    font-size: 30px;
    font-weight: bold;
    color: #fff;
    display: flex;
    align-items: center;
    gap: 10px;
  }
  .botLogo {
    aspect-ratio: 1; /* maintains square dimensions with width */
    border-radius: 50%;
    width: 40px;
    border: 2px solid #5865f2;
  }
  .heading .botLogo {
    width: 180px;
    height: 180px;
    background-color: #5865f2;
    box-shadow: 0px 0px 8px 2px rgba(88, 101, 242, 0.5);
    /* ... */
  }
}

Tai buvo šiek tiek darbo! Bet dabar logotipas yra tinkamai nustatytas kaip komponentas, puikiai tinkantis naujai sluoksnių architektūrai.

Navigacijos sąrašas

Tai tipinis navigacijos modelis. Paimame netvarkingą sąrašą (<ul>) ir paverčiame jį lanksčiu konteineriu, kuris rodo visus sąrašo elementus horizontaliai toje pačioje eilutėje (su leidžiamu perkėlimu). Tai yra daugkartinio naudojimo navigacijos tipas, priklausantis components sluoksniui. Bet prieš jį pridedant, reikia atlikti šiek tiek pertvarkymo.

Jau yra .mainMenu klasė, tad pasinaudokime ja. Pakeisime visus nav ul selektorius šia klase. Vėlgi, tai išlaiko specifiškumą žemą, kartu aiškiau parodant, ką tas elementas daro.

@layer components {
  /* ... */
  .mainMenu {
    display: flex;
    flex-wrap: wrap;
    list-style: none;
  }
  .mainMenu li {
    margin: 0 4px;
  }
  .mainMenu li a {
    color: #fff;
    text-decoration: none;
    font-size: 16px;
    /* ... */
  }
  .mainMenu li a:where(.active, .hover) {
    color: #fff;
    background: #1d1e21;
  }
  .mainMenu li a.active:hover {
    background-color: #5865f2;
  }
}

Taip pat kode yra du mygtukai, naudojami perjungti navigaciją tarp „atidarytos“ ir „uždarytos“ būsenų, kai navigacija susitraukia mažesniuose ekranuose. Tai tiesiogiai susiję su .mainMenu komponentu, todėl viską laikysime kartu components sluoksnyje. Proceso metu galime sujungti ir supaprastinti selektorius, kad stiliai būtų švaresni ir lengviau skaitomi:

@layer components {
  /* ... */
  nav:is(.openMenu, .closeMenu) {
    font-size: 25px;
    display: none;
    cursor: pointer;
    color: #fff;
  }
}

Taip pat pastebėjome, kad keli kiti CSS selektoriai nebuvo naudojami niekur HTML. Taigi, pašalinome tuos stilius, kad viskas būtų tvarkinga. Yra ir automatizuotų būdų tai padaryti.

Medijos užklausos

Ar medijos užklausos turėtų turėti specialų sluoksnį (@layer responsive), ar jos turėtų būti tame pačiame sluoksnyje kaip ir jų tiksliniai elementai? Ilgai svarsčiau šį klausimą, pertvarkydamas šio projekto stilius. Atlikome šiek tiek tyrimų ir testavimo, ir mūsų verdiktas yra pastarasis – medijos užklausos turėtų būti tame pačiame sluoksnyje kaip ir elementai, kuriuos jos veikia.

Mūsų argumentai yra tokie, kad jų laikymas kartu:

Išlaiko prisitaikančius stilius kartu su jų baziniais elementų stiliais,
Padaro perrašymus nuspėjamus, ir
Gerai dera su komponentais pagrįsta architektūra, paplitusia šiuolaikiniame interneto kūrime.

Tačiau tai taip pat reiškia, kad prisitaikymo logika yra išskaidyta po sluoksnius. Bet tai geriau nei variantas su atotrūkiu tarp sluoksnio, kuriame elementai yra stilizuojami, ir sluoksnio, kuriame valdomas jų prisitaikantis elgesys. Mums tai yra esminis trūkumas, nes per lengva atnaujinti stilius viename sluoksnyje ir pamiršti atnaujinti atitinkamą prisitaikantį stilių prisitaikymo sluoksnyje.

Kitas svarbus punktas yra tai, kad medijos užklausos tame pačiame sluoksnyje turi tą patį prioritetą kaip ir jų elementai. Tai atitinka mūsų bendrą tikslą išlaikyti CSS kaskadą paprastą ir nuspėjamą, be stilių konfliktų.

Be to, CSS įdėjimo (angl. nesting) sintaksė labai aiškiai parodo ryšį tarp medijos užklausų ir elementų. Štai sutrumpintas pavyzdys, kaip viskas atrodo, kai įdedame medijos užklausas į components sluoksnį:‍

@layer components {
  .mainMenu {
    display: flex;
    flex-wrap: wrap;
    list-style: none;
  }
  @media (max-width: 900px) {
    .mainMenu {
      width: 100%;
      text-align: center;
      height: 100vh;
      display: none;
    }
  }
}

Tai taip pat leidžia mums įdėti komponento vaikinių elementų stilius (pvz., nav .openMenu ir nav .closeMenu).

@layer components {
  nav {
    &.openMenu {
      display: none;
      
      @media (max-width: 900px) {
        &.openMenu {
          display: block;
        }
      }
    }
  }
}

Tipografika ir mygtukai

.title ir .subtitle gali būti laikomi tipografikos komponentais, todėl jie ir su jais susiję prisitaikantys stiliai eina į – atspėjote – components sluoksnį:

@layer components {
  .title {
    font-size: 40px;
    font-weight: 700;
    /* etc. */
  }
  .subtitle {
    color: rgba(255, 255, 255, 0.75);
    font-size: 15px;
    /* etc.. */
  }
  @media (max-width: 420px) {
    .title {
      font-size: 30px;
    }
    .subtitle {
      font-size: 12px;
    }
  }
}

O kaip dėl mygtukų? Kaip ir daugelyje svetainių, šioje yra klasė .btn šiam komponentui, todėl juos taip pat galime ten įmesti:

@layer components {
  .btn {
    color: #fff;
    background-color: #1d1e21;
    font-size: 18px;
    /* etc. */
  }
  .btn-primary {
    background-color: #5865f2;
  }
  .btn-secondary {
    transition: all 0.3s ease-in-out;
  }
  .btn-primary:hover {
    background-color: #5865f2;
    box-shadow: 0px 0px 8px 2px rgba(88, 101, 242, 0.5);
    /* etc. */
  }
  .btn-secondary:hover {
    background-color: #1d1e21;
    background-color: rgba(88, 101, 242, 0.7);
  }
  @media (max-width: 420px) {
    .btn {
      font-size: 14px;
      margin: 2px;
      padding: 8px 13px;
    }
  }
  @media (max-width: 335px) {
    .btn {
      display: flex;
      flex-direction: column;
    }
  }
}

Paskutinis sluoksnis

Dar nepalietėme utilities sluoksnio! Rezervavome šį sluoksnį pagalbinėms klasėms, skirtoms specifiniams tikslams, pavyzdžiui, turinio slėpimui – arba, šiuo atveju, yra .noselect klasė, kuri puikiai tinka. Ji turi vieną daugkartinio naudojimo tikslą: išjungti elemento pasirinkimą.

Taigi, tai bus vienintelė stiliaus taisyklė mūsų utilities sluoksnyje:

@layer utilities {
  .noselect {
    -webkit-touch-callout: none;
    -webkit-user-select: none;
    -khtml-user-select: none;
    -webkit-user-drag: none;
    -moz-user-select: none;
    -ms-user-select: none;
    user-select: none;
  }
}

Ir viskas! Visiškai pertvarkėme realaus projekto CSS, kad jis naudotų CSS kaskados sluoksnius. Galite palyginti, nuo ko pradėjome, su galutiniu kodu.

Viskas nebuvo taip lengva

Negalima sakyti, kad darbas su kaskados sluoksniais buvo sudėtingas, tačiau proceso metu buvo keletas keblių momentų, kurie privertė mus sustoti ir atidžiai apgalvoti, ką darome.

Dirbdami pasižymėjome kelias pastabas:

Sunku nustatyti, nuo ko pradėti su esamu projektu.Tačiau, pirmiausia apibrėžus sluoksnius ir nustačius jų prioritetų lygius, turėjome sistemą, pagal kurią sprendėme, kaip ir kur perkelti konkrečius stilius, net jei nebuvome visiškai susipažinę su esamu CSS. Tai padėjo išvengti situacijų, kai galėjome abejoti savimi ar apibrėžti papildomus, nereikalingus sluoksnius.
Naršyklių palaikymas vis dar yra problema!Turiu omenyje, kad kaskados sluoksniai, rašant šį straipsnį, turi 94 % palaikymo aprėptį, bet galbūt esate viena iš tų svetainių, kurios turi prisitaikyti prie senų naršyklių, negalinčių palaikyti sluoksniuotų stilių.
Nebuvo aišku, kur procese tinka medijos užklausos.Medijos užklausos privertė mus ieškoti, kur jos geriausiai veikia: įdėtos į tuos pačius sluoksnius kaip ir jų selektoriai, ar visiškai atskirame sluoksnyje? Kaip žinote, pasirinkome pirmąjį variantą.
!important raktinis žodis yra žongliravimo veiksmas.Jie apverčia visą sluoksnių prioritetų sistemą, o šis projektas buvo pilnas jų pavyzdžių. Kai pradedate juos šalinti, esama CSS architektūra suyra ir reikalauja balanso tarp kodo pertvarkymo ir esamo kodo taisymo, kad tiksliai žinotumėte, kaip stiliai kaskaduojasi.

Apskritai, kodo bazės pertvarkymas CSS kaskados sluoksniams iš pirmo žvilgsnio atrodo šiek tiek bauginantis. Tačiau svarbu pripažinti, kad viską komplikuoja ne patys sluoksniai, o esama kodo bazė.

Sunku visiškai pakeisti kieno nors esamą požiūrį nauju, net jei naujasis požiūris yra elegantiškas.

Kur kaskados sluoksniai padėjo (o kur ne)?

Sluoksnių nustatymas neabejotinai pagerino kodą. Esame tikri, kad yra ir tam tikrų našumo rodiklių pagerėjimo, nes sugebėjome pašalinti nenaudojamus ir konfliktuojančius stilius, tačiau tikrasis laimėjimas yra lengviau prižiūrimas stilių rinkinys. Lengviau rasti, ko reikia, žinoti, ką daro konkrečios stiliaus taisyklės, ir kur įterpti naujus stilius ateityje.

Tuo pačiu, nesakytume, kad kaskados sluoksniai yra sidabrinė kulka. Atminkite, kad CSS yra neatsiejamai susijęs su HTML struktūra, kurią jis užklausia. Jei HTML, su kuriuo dirbate, yra nestruktūrizuotas ir kenčia nuo „div-ito“, galite drąsiai lažintis, kad pastangos išnarplioti tą netvarką yra didesnės ir apima žymėjimo perrašymą tuo pačiu metu.

CSS pertvarkymas kaskados sluoksniams neabejotinai vertas vien dėl priežiūros patobulinimų.

Gali būti „lengviau“ pradėti nuo nulio ir apibrėžti sluoksnius dirbant nuo pat pradžių, nes yra mažiau paveldėto balasto ir techninės skolos, kurią reikia išspręsti. Bet jei turite pradėti nuo esamos kodo bazės, gali tekti pirmiausia išnarplioti savo stilių sudėtingumą, kad tiksliai nustatytumėte, kiek pertvarkymo jūsų laukia.