Priekinės sąsajos kodo kokybė: „Linting“ ir formatavimas nuosekliam kūrimui

Sparčiai besivystančiame priekinės sąsajos kūrimo pasaulyje dažnai prioritetas teikiamas greitam funkcionalaus kodo pateikimui. Tačiau kodo kokybės nepaisymas ilgainiui gali sukelti daugybę problemų. Šios problemos apima padidėjusias priežiūros išlaidas, sumažėjusį komandos produktyvumą ir varginančią kūrėjų patirtį. Aukštos kokybės priekinės sąsajos kodo kertinis akmuo yra nuoseklus stilius ir geriausios praktikos laikymasis, kurį galima efektyviai pasiekti naudojant „linting“ ir formatavimo įrankius. Šiame straipsnyje pateikiamas išsamus vadovas, kaip suprasti ir įgyvendinti „linting“ ir formatavimą priekinės sąsajos projektuose, užtikrinant nuoseklią ir prižiūrimą kodo bazę visoms pasaulyje išsibarsčiusioms komandoms.

Kodėl priekinės sąsajos kodo kokybė yra svarbi?

Prieš gilinantis į „linting“ ir formatavimo specifiką, panagrinėkime, kodėl priekinės sąsajos kodo kokybė yra tokia svarbi:

• Priežiūra: Švarų, gerai suformatuotą kodą lengviau suprasti ir modifikuoti, supaprastinant priežiūrą ir sumažinant klaidų įvedimo riziką atnaujinimų metu. Įsivaizduokite, kad kūrėjas Bangalore, Indijoje, lengvai supranta kodą, parašytą kolegos Londone, JK.
• Skaitymas: Nuoseklus kodavimo stilius pagerina skaitomumą, todėl kūrėjams lengviau greitai suvokti kodo logiką ir paskirtį. Tai ypač svarbu priimant naujus komandos narius arba bendradarbiaujant projektuose skirtingose laiko zonose ir žemynuose.
• Bendradarbiavimas: Standartizuotas kodo stilius pašalina subjektyvias diskusijas apie formatavimo nuostatas ir skatina sklandesnį bendradarbiavimą kūrimo komandose. Tai labai svarbu paskirstytoms komandoms, kur tiesioginis bendravimas gali būti ribotas.
• Sumažintos klaidos: „Linters“ gali nustatyti galimas klaidas ir anti-modelius prieš vykdymo laiką, užkertant kelią klaidoms ir gerinant bendrą programos stabilumą. Paprastos sintaksės klaidos ankstyvas aptikimas gali sutaupyti valandas derinimo laiko.
• Pagerintas našumas: Nors tai ne visada tiesiogiai susiję, kodo kokybės praktika dažnai skatina rašyti efektyvesnį ir optimizuotą kodą, o tai lemia geresnį programos našumą.
• Integravimo efektyvumas: Nauji komandos nariai gali greitai prisitaikyti prie kodo bazės, jei yra įdiegtas nuoseklus stilius. Tai sumažina mokymosi kreivę ir leidžia jiems veiksmingai prisidėti anksčiau.
• Dalijimasis žiniomis: Standartizuotas kodas leidžia geriau dalytis kodo fragmentais ir bibliotekomis tarp projektų ir komandų.

Kas yra „Linting“ ir formatavimas?

„Linting“ ir formatavimas yra du skirtingi, bet vienas kitą papildantys procesai, kurie prisideda prie kodo kokybės:

„Linting“

„Linting“ yra kodo analizės procesas, siekiant nustatyti galimas klaidas, stiliaus pažeidimus ir įtartinas konstrukcijas. „Linters“ naudoja iš anksto nustatytas taisykles, kad nustatytų nukrypimus nuo nusistovėjusios geriausios praktikos ir kodavimo konvencijų. Jie gali aptikti įvairias problemas, įskaitant:

• Sintaksės klaidos
• Nedeklaruoti kintamieji
• Nenaudojami kintamieji
• Galimos saugumo spragos
• Stiliaus pažeidimai (pvz., nenuoseklus įtraukimas, pavadinimų suteikimo konvencijos)
• Kodo sudėtingumo problemos

Populiariausi priekinės sąsajos „linters“ yra:

• ESLint: Plačiai naudojamas „linter“ JavaScript ir JSX, siūlantis platų tinkinimą ir papildinių palaikymą. Jis yra labai konfigūruojamas ir gali būti pritaikytas įvairiems kodavimo stiliams.
• Stylelint: Galingas „linter“ CSS, SCSS ir kitoms stiliaus kalboms, užtikrinantis nuoseklų stilių ir geriausios praktikos laikymąsi.
• HTMLHint: „Linter“ HTML, padedantis nustatyti struktūrines problemas ir prieinamumo problemas.

Formatavimas

Formatavimas, dar žinomas kaip kodo pagražinimas, yra automatinis kodo išdėstymo ir stiliaus reguliavimo procesas, kad jis atitiktų iš anksto nustatytą standartą. Formatuotojai tvarko tokius aspektus kaip:

• Įtraukimas
• Eilučių tarpai
• Eilučių apvyniojimas
• Citatos stiliai
• Kabliataškių naudojimas

Populiarus priekinės sąsajos formatuotojas yra:

• Prettier: Nuomonę turintis kodo formatuotojas, palaikantis daugybę kalbų, įskaitant JavaScript, TypeScript, CSS, HTML ir JSON. Prettier automatiškai performatuoja jūsų kodą, kad jis atitiktų jo iš anksto nustatytą stilių, pašalindamas subjektyvias formatavimo diskusijas.

ESLint ir Prettier nustatymas priekinės sąsajos projektui

Pereikime per ESLint ir Prettier nustatymo tipiniame priekinės sąsajos projekte procesą. Daugiausia dėmesio skirsime JavaScript/React projektui, tačiau principai taikomi ir kitoms sistemoms bei kalboms.

Būtinos sąlygos

• Įdiegtas Node.js ir npm (arba yarn)
• Priekinės sąsajos projektas (pvz., React programa)

Įdiegimas

Pirmiausia įdiekite ESLint, Prettier ir būtinus papildinius kaip kūrimo priklausomybes:

            npm install eslint prettier eslint-plugin-react eslint-plugin-react-hooks eslint-config-prettier --save-dev
            

              
                Copy
              
            
          

Paketų paaiškinimas:

• eslint: Pagrindinė ESLint biblioteka.
• prettier: Prettier kodo formatuotojas.
• eslint-plugin-react: ESLint taisyklės, skirtos React kūrimui.
• eslint-plugin-react-hooks: ESLint taisyklės, skirtos React Hooks geriausios praktikos įgyvendinimui.
• eslint-config-prettier: Išjungia ESLint taisykles, kurios prieštarauja Prettier.

Konfigūracija

Sukurkite ESLint konfigūracijos failą (.eslintrc.js arba .eslintrc.json) savo projekto šakniniame aplanke. Štai pavyzdinė konfigūracija:

            module.exports = {
  env: {
    browser: true,
    es2021: true,
    node: true,
  },
  extends: [
    'eslint:recommended',
    'plugin:react/recommended',
    'plugin:react-hooks/recommended',
    'prettier',
  ],
  parserOptions: {
    ecmaFeatures: {
      jsx: true,
    },
    ecmaVersion: 'latest',
    sourceType: 'module',
  },
  plugins: [
    'react',
  ],
  rules: {
    'react/react-in-jsx-scope': 'off',
  },
};

            

              
                Copy
              
            
          

Pagrindiniai šios konfigūracijos aspektai:

• env: Apibrėžia aplinką, kurioje bus vykdomas kodas (naršyklė, Node.js, ES2021).
• extends: Nurodo iš anksto nustatytų konfigūracijų rinkinį, iš kurio bus paveldima.
• eslint:recommended: Įjungia rekomenduojamų ESLint taisyklių rinkinį.
• plugin:react/recommended: Įjungia rekomenduojamas ESLint taisykles, skirtas React.
• plugin:react-hooks/recommended: Įjungia rekomenduojamas ESLint taisykles, skirtas React Hooks.
• prettier: Išjungia ESLint taisykles, kurios prieštarauja Prettier.
• parserOptions: Konfigūruoja JavaScript analizatorių, naudojamą ESLint.
• plugins: Nurodo naudojamų papildinių sąrašą.
• rules: Leidžia tinkinti atskiras ESLint taisykles. Šiame pavyzdyje išjungiame taisyklę `react/react-in-jsx-scope`, nes šiuolaikiniuose React projektuose ne visada reikia importuoti React kiekviename komponento faile.

Sukurkite Prettier konfigūracijos failą (.prettierrc.js, .prettierrc.json arba .prettierrc.yaml) savo projekto šakniniame aplanke. Štai pavyzdinė konfigūracija:

            module.exports = {
  semi: false,
  trailingComma: 'all',
  singleQuote: true,
  printWidth: 120,
  tabWidth: 2,
};

            

              
                Copy
              
            
          

Ši konfigūracija nurodo šias Prettier parinktis:

• semi: Ar pridėti kabliataškius sakinių pabaigoje (false reiškia, kad nėra kabliataškių).
• trailingComma: Ar pridėti galines kablelius kelių eilučių objektuose ir masyvuose (all prideda juos, kur įmanoma).
• singleQuote: Ar naudoti viengubas kabutes vietoj dvigubų kabučių eilutėms.
• printWidth: Didžiausias eilutės ilgis, prieš Prettier apvyniojant kodą.
• tabWidth: Tarpų skaičius, naudojamas įtraukimui.

Galite tinkinti šias parinktis, kad jos atitiktų jūsų pageidaujamą kodavimo stilių. Peržiūrėkite Prettier dokumentaciją, kad gautumėte išsamų galimų parinkčių sąrašą.

Integravimas su IDE

Kad gautumėte maksimalią naudą iš ESLint ir Prettier, integruokite juos su savo IDE. Dauguma populiarių IDE (pvz., VS Code, WebStorm, Sublime Text) turi plėtinius arba papildinius, kurie suteikia realaus laiko „linting“ ir formatavimą rašant. Pavyzdžiui, VS Code siūlo ESLint ir Prettier plėtinius, kurie gali automatiškai formatuoti jūsų kodą išsaugojant. Tai yra pagrindinis žingsnis automatizuojant kodo kokybę.

Npm scenarijų pridėjimas

Pridėkite npm scenarijus į savo package.json failą, kad galėtumėte lengvai paleisti ESLint ir Prettier iš komandinės eilutės:

            "scripts": {
  "lint": "eslint . --ext .js,.jsx",
  "format": "prettier --write .",
  "lint:fix": "eslint . --ext .js,.jsx --fix",
  "format:check": "prettier --check ."
}
            

              
                Copy
              
            
          

Scenarijų paaiškinimas:

• lint: Paleidžia ESLint visuose .js ir .jsx failuose projekte.
• format: Paleidžia Prettier, kad suformatuotų visus failus projekte. Vėliavėlė `--write` nurodo Prettier tiesiogiai modifikuoti failus.
• lint:fix: Paleidžia ESLint su vėliavėle `--fix`, kuri automatiškai ištaiso visas pataisomas „linting“ klaidas.
• format:check: Paleidžia Prettier, kad patikrintų, ar visi failai yra suformatuoti pagal konfigūraciją. Tai naudinga CI/CD vamzdynams.

Dabar galite paleisti šiuos scenarijus iš komandinės eilutės:

            npm run lint
npm run format
npm run lint:fix
npm run format:check
            

              
                Copy
              
            
          

Failų ignoravimas

Galbūt norėsite neįtraukti tam tikrų failų ar katalogų iš „linting“ ir formatavimo (pvz., node_modules, build directories). Sukurkite .eslintignore ir .prettierignore failus savo projekto šakniniame aplanke, kad nurodytumėte šiuos išimtis. Pavyzdžiui:

.eslintignore:

            node_modules/
dist/
build/

            

              
                Copy
              
            
          

.prettierignore:

            node_modules/
dist/
build/

            

              
                Copy
              
            
          

Kodo kokybės automatizavimas naudojant CI/CD

Norėdami užtikrinti nuoseklią kodo kokybę visoje savo kūrimo komandoje, integruokite „linting“ ir formatavimą į savo CI/CD vamzdyną. Tai automatiškai patikrins jūsų kodą dėl stiliaus pažeidimų ir galimų klaidų prieš jį sujungiant į pagrindinę šaką.

Štai pavyzdys, kaip integruoti ESLint ir Prettier į GitHub Actions darbo eigą:

            name: CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Use Node.js 16
      uses: actions/setup-node@v3
      with:
        node-version: 16
    - name: Install dependencies
      run: npm install
    - name: Run linters
      run: npm run lint
    - name: Run format check
      run: npm run format:check

            

              
                Copy
              
            
          

Ši darbo eiga atlieka šiuos veiksmus:

• Atsiunčia kodą.
• Nustato Node.js.
• Įdiegia priklausomybes.
• Paleidžia ESLint.
• Paleidžia Prettier tikrinimo režimu.

Jei ESLint arba Prettier aptinka klaidų, darbo eiga nepavyks, užkertant kelią kodo sujungimui.

Geriausia „Linting“ ir formatavimo praktika

Štai keletas geriausių praktikų, kurių reikia laikytis įgyvendinant „linting“ ir formatavimą:

• Nustatykite nuoseklų kodavimo stilių: Apibrėžkite aiškų ir nuoseklų kodavimo stiliaus vadovą savo projektui. Tai turėtų apimti tokius aspektus kaip įtraukimas, eilučių tarpai, pavadinimų suteikimo konvencijos ir komentarų praktika. Apsvarstykite galimybę naudoti plačiai paplitusį stiliaus vadovą, pvz., Airbnb's JavaScript Style Guide, kaip atspirties tašką.
• Automatizuokite procesą: Integruokite „linting“ ir formatavimą į savo kūrimo darbo eigą ir CI/CD vamzdyną. Tai užtikrins, kad visas kodas atitiktų nustatytas stiliaus gaires.
• Tinkinkite taisykles: Sureguliuokite ESLint ir Prettier taisykles, kad jos atitiktų konkrečius jūsų projekto reikalavimus ir nuostatas. Nebijokite išjungti taisyklių, kurios nėra svarbios arba prieštarauja jūsų kodavimo stiliui.
• Naudokite redaktoriaus integraciją: Integruokite „linters“ ir formatuotojus tiesiogiai į savo IDE, kad gautumėte grįžtamąjį ryšį realiuoju laiku. Tai padeda anksti sugauti klaidas ir nuosekliai įgyvendinti stilių.
• Švieskite komandą: Užtikrinkite, kad visi komandos nariai žinotų „linting“ ir formatavimo taisykles ir suprastų, kaip naudoti įrankius. Pateikite mokymus ir dokumentaciją, jei reikia.
• Reguliariai peržiūrėkite konfigūraciją: Periodiškai peržiūrėkite savo ESLint ir Prettier konfigūracijas, kad įsitikintumėte, jog jos vis dar yra svarbios ir veiksmingos. Kai jūsų projektas vystosi, gali tekti pakoreguoti taisykles, kad atspindėtų naują geriausią praktiką arba kodavimo konvencijas.
• Pradėkite nuo numatytųjų reikšmių ir palaipsniui tinkinkite: Pradėkite nuo rekomenduojamų arba numatytųjų ESLint ir Prettier konfigūracijų. Palaipsniui tinkinkite taisykles ir nustatymus, kad jie atitiktų jūsų komandos nuostatas ir projekto reikalavimus.
• Atsižvelkite į prieinamumą: Įtraukite prieinamumo „linting“ taisykles, kad anksti kūrimo procese sugautumėte dažnas prieinamumo problemas. Tai padeda užtikrinti, kad jūsų programa būtų tinkama naudoti žmonėms su negalia.
• Naudokite commit hooks: Integruokite „linting“ ir formatavimą į savo Git darbo eigą naudodami commit hooks. Tai automatiškai patikrins jūsų kodą prieš kiekvieną commit ir neleis jums commit kodo, kuris pažeidžia stiliaus gaires. Tokios bibliotekos kaip Husky ir lint-staged gali padėti automatizuoti šį procesą.
• Laipsniškai spręskite techninę skolą: Įvesdami „linting“ ir formatavimą į esamą projektą, laipsniškai spręskite techninę skolą. Pirmiausia sutelkite dėmesį į naują kodą ir palaipsniui performatuokite esamą kodą, kad jis atitiktų stiliaus gaires.

Iššūkiai ir svarstymai

Nors „linting“ ir formatavimas siūlo didelę naudą, taip pat reikia atsižvelgti į kai kuriuos iššūkius ir svarstymus:

• Pradinis nustatymas ir konfigūracija: ESLint ir Prettier nustatymas gali užtrukti, ypač sudėtingiems projektams. Tam reikia kruopščios konfigūracijos ir tinkinimo, kad atitiktų jūsų konkrečius poreikius.
• Mokymosi kreivė: Kūrėjams gali prireikti išmokti naujų įrankių ir kodavimo konvencijų, o tai gali užtrukti.
• Galimi konfliktai: ESLint ir Prettier kartais gali prieštarauti vienas kitam, todėl reikia kruopščios konfigūracijos, kad būtų išvengta netikėto elgesio.
• Vykdymas: Gali būti sunku nuosekliai įgyvendinti „linting“ ir formatavimo taisykles didelėje kūrimo komandoje, ypač globaliai paskirstytose aplinkose. Būtinas aiškus bendravimas, mokymas ir automatiniai patikrinimai.
• Perdėtas tinkinimas: Venkite per daug tinkinti taisykles, nes tai gali lemti griežtą ir nelanksčią kodavimo stilių. Kai įmanoma, laikykitės plačiai pripažintos geriausios praktikos ir kodavimo konvencijų.
• Našumo poveikis: „Linting“ ir formatavimas gali turėti nedidelį našumo poveikį, ypač dideliuose projektuose. Optimizuokite savo konfigūraciją ir darbo eigą, kad sumažintumėte šį poveikį.

Išvada

„Linting“ ir formatavimas yra esminė praktika norint išlaikyti aukštos kokybės priekinės sąsajos kodą, ypač dirbant su globaliai paskirstytomis komandomis. Automatizuodami kodo stiliaus vykdymą ir anksti nustatydami galimas klaidas, galite pagerinti kodo skaitomumą, prižiūrimumą ir bendradarbiavimą. Nors reikia atsižvelgti į kai kuriuos iššūkius, „linting“ ir formatavimo privalumai gerokai viršija trūkumus. Laikydamiesi geriausios praktikos, aprašytos šiame straipsnyje, galite nustatyti nuoseklų kodavimo stilių, sumažinti klaidas ir pagerinti bendrą savo priekinės sąsajos programų kokybę, nepriklausomai nuo to, kur yra jūsų komandos nariai.

Investavimas į kodo kokybę yra investicija į ilgalaikę jūsų projekto sėkmę ir kūrimo komandos produktyvumą. Įtraukite „linting“ ir formatavimą kaip savo kūrimo darbo eigos dalį ir mėgaukitės švaresnės, geriau prižiūrimos kodo bazės privalumais.