(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start': new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0], j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src= 'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f); })(window,document,'script','dataLayer','GTM-5LHNRP9'); Gæði fyrst! 5 einföld skref til að lint-a kóðann þinn með GitHub-vinnuflæðum í JavaScript-verkefninu - The Codest
The Codest
  • Um okkur
  • Þjónusta
    • Hugbúnaðarþróun
      • Framhliðþróun
      • Bakendaþróun
    • Staff Augmentation
      • Framhliðaráþrófarar
      • Bakhliðaráþróunaraðilar
      • Gagnaverkfræðingar
      • Skýjaverkfræðingar
      • Gæðatryggingartæknimenn
      • Annað
    • Það er ráðgjafi
      • Endurskoðun og ráðgjöf
  • Iðnaðargreinar
    • Fjártæknifyrirtæki og bankastarfsemi
    • E-commerce
    • Adtech
    • Heilbrigðistækni
    • Framleiðsla
    • Flutningar
    • Bifreiða
    • Internet hlutanna
  • Gildi fyrir
    • CEO
    • CTO
    • Afhendingarstjóri
  • Teymið okkar
  • Case Studies
  • Vitið hvernig
    • Blogg
    • Fundir
    • Vefnámskeið
    • Auðlindir
Starfsferilmöguleikar Hafðu samband
  • Um okkur
  • Þjónusta
    • Hugbúnaðarþróun
      • Framhliðþróun
      • Bakendaþróun
    • Staff Augmentation
      • Framhliðaráþrófarar
      • Bakhliðaráþróunaraðilar
      • Gagnaverkfræðingar
      • Skýjaverkfræðingar
      • Gæðatryggingartæknimenn
      • Annað
    • Það er ráðgjafi
      • Endurskoðun og ráðgjöf
  • Gildi fyrir
    • CEO
    • CTO
    • Afhendingarstjóri
  • Teymið okkar
  • Case Studies
  • Vitið hvernig
    • Blogg
    • Fundir
    • Vefnámskeið
    • Auðlindir
Starfsferilmöguleikar Hafðu samband
Aftur ör Farðu aftur
2019-04-14
Hugbúnaðarþróun

Gæði fyrst! 5 einföld skref til að lint-a kóðann þinn með GitHub-vinnuflæði í JavaScript-verkefninu

Vojtech Bak

Gæði kóðans eru mikilvægur hluti af þróunarferlinu, sérstaklega þegar þú vilt vinna skilvirkt til lengri tíma. Það eru til margar nálganir og bestu vinnubrögð, þar á meðal heilar agílar aðferðafræði, en flestar þeirra tengjast stórum fyrirtækja­verkefnum sem unnin eru af að minnsta kosti sex manns.

Hér er tómt.

Hvað eigum við að gera þegar verkefni er lítill eða viðskiptavinurinn veit enn ekki hvort það sé þess virði að fjárfesta meira? Augljóslega, hjá MVP-fasi verkefnisins, kóði Stílun eða einingapróf eru ekki æðsta forgangsatriði. Fjárfestar vilja yfirleitt hafa gott vara og komdu nú – ef það virkar, þarf það ekki að prófa, er það ekki?

Reyndar hef ég nokkra reynslu af Að byggja upp forrit frá grunni, jafnvel án þess að beita bestu starfsháttum frá upphafi. Sumar viðskiptalegar aðstæður neyddu mig til að leita málamiðlunar milli fjárfestaplana um fjárhagsáætlun og „nice-to-have”-lista forritarans. Sem betur fer, ef þú notar GitHub, er hægt að leysa flestar algengar villur sem tengjast kóðagæðum á nokkrum mínútum.

Í þessari grein ætla ég að sýna þér hvernig á að nota GitHub-vinnuflæði í Node.js-umhverfinu til að staðla kóðagrunninn þinn.

Fáar forsendur áður en við byrjum:

  • Þú þekkir NPM og Linux-skjáinn.
  • Þú hefur nokkra reynslu af stílfyrirvinnslum, einingalóðurum, bundlara o.s.frv.
  • Þú veist hvað linterar eru til og vilt virkilega nota þá í verkefnum þínum.

1. Algeng verkefnisuppbygging JavaScript

Ef þú hefur einhvern tíma notað eitthvað JS rammasetningar eins og Vue eða React, þú getur auðveldlega séð nokkra sameiginlega hluti á milli þeirra, t.d.:

  • /uppspretta möppu með allri JS-skilgreiningu þinni og íhlutum,
  • próf skrá fyrir eininga- og end-to-end-prófanir,
  • eignir möppu fyrir stíla, myndir o.s.frv.

Jafnvel þó við séum að tala um JavaScript verkefni, sem við vinnum í Knútur umhverfi, svo augljóslega ætti einnig að vera eitthvað Node-tengt eins og package.json, package-lock.json og /nútímamódúlum skráarsafn í rótarmöppunni okkar.

Allt þetta er á sínum stað – það er það sem við köllum samkoma. Rammaskipulög eru fundin upp til að bjóða upp á sanngjarnar venjur, svo yfirleitt þurfum við ekki einu sinni að hafa áhyggjur af upphaflegu hönnunarmynstri. Eins og í þessu dæmi vil ég útskýra nokkrar nálganir; ég mun ekki beita neinum tilbúnum lausnum eins og Vue CLI.

Tími er kominn til að skilja hvað liggur undir öllum þessum töfraduft-skriptum!

2. Að stækka dæmigerða Node-verkefnið

Til að bjóða upp á hágæða lausnir eru linterar það fyrsta sem við ættum að byrja á þegar við setjum upp nýtt verkefni. Skulum einbeita okkur að tveimur linterum – Stylelint fyrir stíla (*.scss) og ESLint fyrir upprunaskrár (stjörnu-js). Báðir þessir linterar eru fáanlegir á NPM og nokkuð auðvelt að stilla þá. Til að nota linterana þarf að fara í gegnum uppsetningarferlið, bæta við stillingarskrám og skilgreina verkefnisskriptur. Skulum gera þetta skref fyrir skref.

3. Bæta við Stylelint

Uppsetning Stylelint í Node-umhverfinu er mjög einföld. Samkvæmt opinber skjöl, þú þarft bara að keyra:

npm install --save-dev stylelint stylelint-config-standard

og bíða þar til það er búið.

stíl-línslausn-staðall veitir sjálfgefinn safn kóðaskoðunarreglna og má skipta út fyrir hvaða pakka sem betur hentar þínum þörfum (t.d. Á Airbnb-máta). Búðu síðan til nýjan falinn skrá. .stylelintrc.json, sem er Stylelint stillingarskrá, ábyrg fyrir að hlaða fyrirfram skilgreindum reglum okkar:

{
    "extends": "stylelint-config-standard"
}

Núna er eina sem vantar nokkur NPM-skrift (eða skriftir) tilgreind í package.json-skránni til að hefja lintun á SCSS-skrám okkar. Hér er tillaga mín:

"scripts": {
    "lint:scss": "stylelint '**/*.scss' --syntax scss -f verbose --color",
    "lint:scss:fix": "stylelint '**/*.scss' --syntax scss --fix -f verbose —color"
}

Eins og þú sérð hef ég lýst skriftunni sem inniheldur —lagfæra valkostur – þennan skal nota áður en breytingar eru sendar í geymsluna.

Mundu – það er slæmt vinnubrögð að nota —lagfæra í CI-ferlinu þínu, því kóðinn sem fer í framleiðslu er þá ekki stíllaður rétt í geymslunni. Þess vegna þurfum við bæði handritin.

Skoðum linterinn okkar með því að búa til skrá. /assets/scss/styles.scss með nokkru efni, eins og:

líkami {
 bakgrunnslitur: #fff;
}
npm run lint:scss

Þú ættir að sjá í skráningarbókinni þinni eitthvað svona:

> stylelint '**/*.scss' --syntax scss -f verbose --color

assets/scss/styles.scss

2:21  ✖ Búist var við 2 tómstafa innstigi   innstig

1 uppspretta skoðuð

~/Codest/Projects/github-workflow-demo/assets/scss/styles.scss

1 vandamál fundið

alvarleikastig "error": 1

innstigning: 1

npm ERR! code ELIFECYCLE

npm ERR! errno 2

npm ERR! [email protected] lint:scss: `stylelint '**/*.scss' --syntax scss -f verbose --color`

npm ERR! Útgangskóði 2

Þetta þýðir í raun að linterinn okkar virkar!

Úttakið sýnir nákvæmlega hvaða lína veldur villu og lýsir vandamálinu sem þarf að leysa. Sum vandamál er ekki hægt að laga sjálfkrafa þar sem þau krefjast ákvörðunar forritara, en í flestum tilfellum þarftu bara að keyra sama skipunina með —lagfæra valkostur, svo keyrum hann.

npm run lint:scss:fix

Nú ættir þú að sjá grænt úttak án nokkurra villa:

stylelint '**/*.scss' --syntax scss --fix -f verbose --color


1 uppspretta skoðuð

/Users/wojciechbak/Codest/Projects/github-workflow-demo/assets/scss/styles.scss

0 vandamál fundin

4. Bæta við ESLint

Þetta skref er nánast það sama og það fyrra. Við ætlum að setja upp ESLint, skilgreina nokkur sjálfgefin reglur og lýsa tveimur kallanlegum NPM-skriptum – eitt fyrir CI og eitt fyrir pre-push. Skulum fara í gegnum þetta!

Ef þú notar NPM í daglegu starfi þínu gætirðu viljað setja ESLint upp á heimsvísu. Ef þú gerir það ekki, vinsamlegast skoðaðu uppsetningarleiðbeiningarnar í opinber skjöl.

npm install -g eslint

Þegar eslint-skipunin er tiltæk á vélinni þinni, keyrðu einfaldlega þetta í verkefninu þínu:

eslint --init

Eftir frekari leiðbeiningar sem birtast í skjálinum þínum, gerðu einfaldlega nokkrar ákvarðanir um verkefnið, eins og:

  • JavaScript eða TypeScript
  • Á Airbnb-stíl eða Google-stíl
  • stillingargerð (JSON-skrá, JS-skrá eða inn í) package.json)
  • ES-modúlar (innflutningur/útflutningur) eða krefjast setningafræði

Hér er þess virði að skrifa nokkur orð um kóðaforvinnslutól sem kallast Prettier. Það er fullkomlega staðlað og samhæft við flesta kóðaritla (t.d. VS Code). Prettier býður upp á mörg forstillt sett af reglum um kóðastíl, vinnur með linterum og getur verið mikil hjálp við að tryggja sem bestu gæði kóðans. Til að skilja nákvæmlega hvað Prettier er, heimsækið þetta samanburður úr opinberum skjölum.

Ef það er gert, ESLint stillingarskrá (t.d. .eslintrc.json, fer eftir því hvað þú hefur valið áður) ætti að birtast í rótarmöppunni þinni, einhvers staðar við hliðina á .stylelintrc.json búa til áður.

Nú verðum við að skilgreina skriptur í package.json skrárna, eins og fyrir SCSS-skrár:

"scripts": {
    "lint:js": "eslint '**/*.js' --ignore-pattern node_modules/",
    "lint:js:fix": "eslint '**/*.js' --ignore-pattern node_modules/ --fix"
}

Til hamingju! ESLint er tilbúið til notkunar strax. Skulum athuga hvort það virki rétt. Búðu til /upphafskóði/vísitalan.js skrá með einhverju efni:

Skráðu eitthvað í vafra-skjáinn.;

Keyra linter:

npm run lint:js


Úttakið ætti að líta svona út:

eslint '**/*.js' --ignore-pattern node_modules/

~/Codest/Projects/github-workflow-demo/src/index.js

1:1  viðvörun  Óvænt console-yfirlýsing  no-console

✖ 1 vandamál (0 villur, 1 viðvörun)

Þessi viðvörun hverfur ekki eftir notkun. –lagfæra valkostur, vegna linters hefur ekki áhrif á hugsanlega merkingarbæran kóða. Þeir eru eingöngu til kóðastíls., þar á meðal tómarými, línubrot, semíkólon, gæsalappir o.s.frv.

5. Að skilgreina GitHub-vinnuflæði

Vinnuflæði GitHub Þetta er nokkuð vel skjalfest. Endilega skoðaðu þetta nánar, en í bili ætla ég að innleiða einfalda vinnsluaðferð til að lint-skoða kóðann okkar eftir að kóðanum er ýtt á fjarlæga geymsluna (auðvitað hýst á GitHub).

Búa til /.github/workflows skrá og nýtt kóðagæðavinnslaflæði.yml skrá þar þar sem GitHub-vinnsuferlar þurfa að vera skilgreindir með YAML-skrám.

Til að reka rétt vinnuflæði verðum við að svara nokkrum spurningum:

  • Hvenær viljum við keyra vinnuflæðið okkar (við push, við pull-beiðni, við samruna o.s.frv.)?
  • Við viljum við útiloka sumar aðstæður (eins og að ýta á master-grein)?
  • Hvaða umhverfi þurfum við að setja upp til að keyra skipanir okkar rétt (í þessu dæmi – Node)?
  • Þurfum við að setja upp háðarkerfi? Ef svo er, hvernig ættum við að kassa það?
  • Hvaða skref þurfum við að taka til að ljúka athuguninni?

Eftir nokkrar íhuganir og nokkra klukkutíma vinnu með dæmi í skjölunum .yml Skráin getur litið svona út:

nafn: Kóða gæði

á: 'push'

verk:
  kóða-gæði:
    nafn: Lint uppsprettukóða
    keyrir-á: ubuntu-latest
    skref:
    - notar: actions/checkout@v1

 - nafn: Setja upp Node
 notar: actions/setup-node@v1
      with:
 node-version: '12.1'

 - name: Geyma háðarkerfi
 uses: actions/cache@v1
 with:
 path: ./node_modules
 key: $(( runner.OS ))-dependencies-$(( hashFiles('**/package-lock.json** ))
 restore-keys: |
 $(( runner.OS ))-dependencies-$(( env.cache-name ))-
 $(( runner.OS ))-dependencies-
 $(( runner.OS ))-

    - name: Setja upp háðniraðila
 run: |
 npm install

 - name: Lint-skoða skrár
 run: |
 npm run lint

GitHub veitir allt umhverfislegt efni sem við þurfum. Í síðasta línunni keyrum við skipunina. npm run lint sem var ekki skilgreint áður:

"scripts": {
    "lint": "npm run lint:js && npm run lint:scss"
}

Athugaðu að í vinnuflæði okkar er ég ekki að nota :lagfæra skipanir.

Þegar öllum þessum skrefum er lokið geturðu notið þessarar fallegu úttaks frá GitHub áður en þú sameinar Pull Request-ið þitt:

Tengdar greinar

Lausnir fyrir fyrirtæki og vaxtarfyrirtæki

Bestu vinnubrögð við að byggja upp sterkt og samheldið teymi

Samvinna er lykilatriði fyrir árangur í hugbúnaðarþróun. Sterkt team sem vinnur vel saman getur náð betri árangri og yfirstigið áskoranir. Til að efla samvinnu þarf fyrirhafnar, samskipti og stöðuga...

The Codest
Krystian Barchanski Einingarleiðtogi framenda
Hugbúnaðarþróun

Hvernig á að innleiða Agile Methodology?

Náðu tökum á Agile-aðferðafræði með bestu starfsháttum fyrir árangursríka innleiðingu og bætta verkefnastjórnun í hugbúnaðarþróun.

THECODEST

Gerðu þig áskrifanda að þekkingargrunni okkar og vertu upplýstur um sérfræðiþekkingu upplýsingatæknigeirans.

    Um okkur

    The Codest – Alþjóðlegt hugbúnaðarþróunarfyrirtæki með tæknimiðstöðvar í Póllandi.

    Bretland - Höfuðstöðvar

    • Skrifstofa 303B, 182-184 High Street North E6 2JA
      Lundúnir, England

    Pólland - staðbundin tæknimiðstöðvar

    • Fabryczna skrifstofugarður, Aleja
      Herbergi 18, 31-564 Kraków
    • Brain Embassy, Konstruktorska
      11, 02-673 Varsjá, Pólland

    The Codest

    • Heim
    • Um okkur
    • Þjónusta
    • Case Studies
    • Vitið hvernig
    • Starfsferilmöguleikar
    • Orðabók

    Þjónusta

    • Það er ráðgjafi
    • Hugbúnaðarþróun
    • Bakendaþróun
    • Framhliðþróun
    • Staff Augmentation
    • Bakhliðaráþróunaraðilar
    • Skýjaverkfræðingar
    • Gagnaverkfræðingar
    • Annað
    • Gæðatryggingartæknimenn

    Auðlindir

    • Staðreyndir og goðsagnir um samstarf við utanaðkomandi hugbúnaðarþróunaraðila
    • Frá Bandaríkjunum til Evrópu: Af hverju ákveða bandarísk sprotafyrirtæki að flytja til Evrópu?
    • Samanburður á tæknifjarkerfisþróunarmiðstöðvum: Tech Offshore Europe (Pólland), ASEAN (Filippseyjar), Eurasia (Tyrkland)
    • Hvert eru helstu áskoranir CTO-a og CIO-a?
    • The Codest
    • The Codest
    • The Codest
    • Privacy policy
    • Website terms of use

    Höfundarréttur © 2026 af The Codest. Öll réttindi áskilin.

    is_ISIcelandic
    en_USEnglish de_DEGerman sv_SESwedish da_DKDanish nb_NONorwegian fiFinnish fr_FRFrench pl_PLPolish arArabic it_ITItalian es_ESSpanish nl_NLDutch etEstonian elGreek pt_PTPortuguese cs_CZCzech lvLatvian lt_LTLithuanian is_ISIcelandic