před časem pomáhám juniorskému vývojáři, který má na něm zjevný problém, aby zjistil, co se na něm děje. Nainstaloval vlákna a stáhl (Bůh ví proč) přizpůsobený slovník. Připravil jsem si trochu testovací prostředí a ukázal mu rozdíl mezi různými testy, v různých bodech a některými omezeními každého (v tomto malém prostředí).
Nedávno jsem mluvil o testování s kolegou a vzpomněl jsem si na tuto anekdotu a řekl jsem si, abych o tom napsal příspěvek, protože by to pro mnohé mohlo být zajímavé.,
co je linting?
Linting je automatická kontrola zdrojového kódu pro programové a stylistické chyby. To se provádí pomocí nástroje lint (také znám jako linter). Nástroj lint je základní statický analyzátor kódu.
termín linting původně pochází z Unix nástroj pro C. Existuje mnoho kódu lintr k dispozici pro různé programovací jazyky dnes.
programování vláken je typ automatizované kontroly. Může se to stát brzy ve vývoji, před recenzemi a testováním kódu. Je to proto, že automatizované kontroly kódu zefektivňují procesy kontroly kódu a testování., A osvobodí vaše vývojáře, aby se zaměřili na správné věci.
Mnoho automatických nástrojů pro testování využít vestavěný linter házet chyby, nastavit některé skóre o kvalitu kódu a blokovat sestavení nebo nasadit fázi, pokud toto skóre je nižší než požadovaný (automaticky nebo pozastavení procesu házení oznámení, aby ručně zkontrolovat, zda tato „chyby“ by měly být opravené, nebo ne).
k čemu je určen?
Linting je určen ke snížení chyb a zlepšení celkové kvality kódu devs, urychlení vývoje a snížení nákladů nalezením chyb dříve.,
kdy používat software Lint?
Pokud je to pro vás nové, můžete být v tomto okamžiku trochu medializováni s odstíny, ale nejsou programově nástrojem. Lint je jednoduše“scrapper“ /File reader skript se souborem (obvykle json nebo xml) s předdefinovanými (nebo přizpůsobenými) pravidly o tom, jak musí kód vypadat. Ve skutečnosti IDEs mají vestavěný vlákna, která vám bude hodit chybu (tj. pokud voláte neexistující metodu, nebo pokud se pokusíte přidat hodnotu řetězce do celočíselné proměnné) nebo varování (tj., pokud deklarováte proměnnou uvnitř podmíněného a pak tuto proměnnou vrátíte na konci své metody). Ale nemluvím o vestavěném kódu lint, protože tyto linters jsou „měkké“ a tolerantní, jinak mnoho lidí nebude používat tyto IDEs, uvidíme, proč později.
můžete použít konkrétní vlákna, pokud se vejdete do těchto příkazů:
při použití interpretovaných programovacích jazyků.
některé jazyky jsou vhodnější pro linting kódu než jiné. PHP, Python a JavaScript jsou interpretovány jazyky, to znamená, že jim chybí fáze kompilace*., Použití softwaru lint je tedy účinné pro zajištění konzistentního stylu kódování a řešení základních chyb kódování v těchto případech.
ale pokud jde o kompilované jazyky, jako jsou C A C++, používání softwaru lint nemusí stačit. C A C++ jsou složité a mohou vyžadovat pokročilejší analýzu kódu.
* možná křičíte, že kompiluji JavaScript! ale ve skutečnosti to není pravda. V současné době na front end používáme nástroje, jako jsou svazky, přidání některých nástrojů JavaScriptu, které procházejí našimi js některými fázemi, jako je minify, ugglify, ofuscate. Některé z těchto nástrojů také odstraní nepoužitý kód na jeho výstupu., Ale nic z toho neznamená, že kompilujete javascript, protože výstup bude a .js soubor stejně; Žádný bytecode, Žádný assembler.
Je pravda, že můžete převést javascript do webové sestavy, ale není to přímá cesta z jednoho do druhého; musíte převést js na něco „kompilovatelného“ takového kódu C a poté jej zkompilovat do webové sestavy.
při použití standardních pravidel
je to trochu složité prohlášení., Na programovací jazyk, nebudete moci používat něco, co není postaveno na programovacím jazyce (to je vůbec pravda, tak se můžete přidat knihovny nebo hodit systému příkazy z programovacích jazyků, ale stejně nepouští Vlákna nemají nic společného s tím…)
jaká standardní pravidla znamenají?
použití rámce se zde hodí hezky, musíte použít vestavěné metody rámce k dosažení požadovaného výstupu.
někdy standardní pravidla znamená módně kód., Tento metodik a řešení, které společenství opakovat jako mantru, dokud se nenajde další módně způsob, jak dosáhnout cíle daného úkolu, nebo dokud někdo s veřejnou odezva vypráví společenství „hej, byl jsem analýze tohoto řešení a zjistil jsem, že existuje lepší způsob, jak dosáhnout to pro to důvody“ a pak společenství se pohybuje na.
Pokud jsou vaše potřeby základní
Lint nástroje jsou skvělé pro základní analýzu. Pokud však potřebujete sofistikovanější analýzu, musíte hledat jinde (automatizované testovací nástroje a vývoj založený na testech).
kde mám vidět vlákna?
1., Na automatizovaných testů (říkáme jim automatizované protože běží automaticky, ale někdo potřebuje, aby kód testu pro každý případ použití na aplikace), jako jsou Cypřiše, můžete přidat nečistoty do skóre kód kvality.
to může běžet na dobu vývoje (když dev narazí na testovací tlačítko) nebo pravděpodobně na fázi nasazení. Například, když budete tlačit něco do master větve by to mohlo být spoušť pro zvýšení testů, včetně nepouští vlákna, a blokovat nasazení (a obviňovat vás) pokud jste udělal něco špatně, pak se budete muset opravit nebo najít chybu (to neznamená, že je to vaše chyba., Mohl bych tlačit API, které způsobí, že váš klient crash obdrží neočekávané hodnoty, a to bude moje chyba, ne vaše).
Tyto testy nejsou určeny na vině vy, ale na pomoc v procesu vývoje, to je obvykle lepší, aby najít chybu před integrací do pre-produkční fázi v důsledku selhání testu, než najít to překvapení do výroby.
2. Na velkých projektech, obvykle na velkých společnostech., Pokud jste na velmi velké společnosti projektový manažer by měl stejně jako všechny kód vypadají jako stejné (formátování), tak oni asi mají žmolky na to někde, že bod, který jste, pokud jste přidali 4 mezer pro odsazení něco chtějí, s 2, a to bude vyčítat, jestli jste se nechtěl deklarovat metodu s velbloudí případě, například.,
najít tóny junior vývojáři se snaží bojovat proti tomu, protože se jim líbí nějaký konkrétní formátování, ale bez tohoto nástroje, to je velká softwarová aplikace bude vypadat jako frankenstein monstrum na budoucnost zvyšuje obtížnost na čtení všechny díly, nebo na základě některé metody, cesty a třída přepíše. Přemýšlejte o tom, jako byste si přečetli knihu o tom, kde každý odstavec má jinou velikost písma, rodinu písma atd.
kde ji nepoužívat?
tento bod je tak snadný: nepoužívejte jej v dynamickém kontextu a v neprogramovacích jazycích.
1. První je snadno pochopitelná., Pokud jste v dynamickém kontextu, vlákna (statická kontrola) nikdy nepoznají konečný výsledek a budou vás obviňovat za věci, které jsou v pořádku, přidám nějaký příklad k dalšímu bodu.
2. To by mělo znít směšně, redundantně nebo mi můžete říct “ kde používáte vlákna, pokud to není v programovacím jazyce?“
Mulder, tam jsou HTML a CSS linters venku.
Ano.. zasraný… Ale jak?,
No, oni nejsou druhořadé ve skutečnosti, oni jsou jen kód-dáma, totéž můžete udělat s w3c validátor, ale místo toho na kopírování kódu do validátoru, oni obvykle běžet na čas vývoje viní z toho, různé věci na základě něčí názor, což je nepříjemné, nepřesné a opravdu nehodí v dnešní době použití těchto dvou technologií (nebo tři, pokud přidáte SCSS), a co je nejdůležitější, oni obvykle nemají důvod pro každý příkaz, nebo důvody rozporu z bodu do druhého, nebo důvod, proč je zastaralé, nebo důvody nejsou platné pro všechny projekty., To je důvod, proč najdete tóny „Zapomeňte na CSSLint, je to umíněný a neodpovídá vašemu projektu“ komentáře a mnoho podobných dalších na internetu.
najdete některé kusy kódu, které se z nějakého důvodu nazývají Linters, ale alespoň vám řeknou „jsem umíněný formátovač kódu“, jako je tento .,
HTML nečistoty by mohly být užitečné občas, jak to bude nutit vás k přidání atributu alt pro obrázky a další přístupnost a osvědčených postupů (Většina Ide zobrazuje varování o to taky bez přidání vlákna, které je lepší) ale to vám nezabrání v používání <span> <p> nebo jiné špatné html použití.
také vás bude obtěžovat, pokud píšete komponenty šablon s hloupými prohlášeními jako „nemáte deklaraci doctype, nemáte html, head, title ani body tag., A ty by mohly věc „samozřejmě, jak tento soubor bude načten uvnitř dokumentu, který již má tagy“, ale HTML vlákna nesmí vědět; Lints jsou statické dáma a pracujete na dynamické prostředí, a tak dál a odstranit html nepouští vlákna.
CSSLint je trochu jiný, není žádná věc, kterou můžete nepouští vlákna tady, mimochodem, můžete napsat platný nebo neplatný CSS, ale to je vše.,
Existují osvědčené postupy na CSS, které stojí za účinnost a rychlost účely (to bude také přínosem pro UX), jiní, že půjde o udržovatelnost, rozšiřitelnost a čitelnost účely (obvykle na základě zkušenosti s vývojem), další z nich stojí za dostupnost (na základě UI/UX studií a prohlížeč omítky, kontrastu obrazovky, testy a tak). Ale nemá smysl na to všechno spojit do linter a říká, devs, aby odpovídaly všechny ty postupy, v první řadě, protože tam jsou rozpory, které potřebuje člověk, aby se rozhodnutí o použití jednoho nebo druhého.,
use case, kam se vybrat, by mohla být řešena tím, že přidá všechny přístupnost CSS kódu bude observably zvýšit velikost, doba načítání, a poprvé interaktivní metriky, takže si obvykle vybere pouze pravidla přístupnosti, které se nejlépe hodí pro vaše zákazníky při zachování dobrého výkonu.
Pro nastavení hloupý příklad, o umíněný pravidlo na CSSLint řekněme, že chci lineární gradient jako pozadí na domovskou stránku hlavní blok. CSSLint bude hodit varování o lineárním gradientu výkonu.,
V tomto bodě CSSLint chcete odstranit lineární gradient, ale jaké jsou alternativy?
použití obrazu bude tóny krát méně efektivní pro dosažení cílového designu (a také sníží vizuální kvalitu gradientu, a bude těžší změnit velikost, aby se vešly všechny polohovatelné velikosti bloku).
takže co můžeme dělat? Jednoduše ignorujte CSSLint, protože je umíněný a to není z jakéhokoli důvodu podporováno.
je rozdíl při přidávání lineárního gradientu vs přidáním lineárních gradientů 42342 ve stejném zobrazení., Mimochodem, pokud je potřebujete, bude to stále efektivnější než použití obrázků.
najdete na něm také protichůdná prohlášení:
„nepoužívejte ID pro styling“. Důvodem je, že to bude pravidlo, které není znovu použitelné.
a
„nepoužívejte sousední třídy“. Nemohl jsem správně zjistit důvod, aniž bych četl vysvětlení pravidel CSS lint a důvod je „zatímco je to technicky povoleno v CSS,nejsou s nimi správně zacházeno pomocí aplikace Internet Explorer 6 a starší“.
Mám vám co říct CSSLint., Nikdo se nestará o IE 6 a dříve, jsme v roce 2020, 99% webového softwaru podporuje i.e. 11 tolik, který byl propuštěn na 2013 mimochodem a má méně než 3% využití.
na druhou stranu, kde je proboha vyjádřeno, že všechna pravidla CSS musí být znovu použitelná na stejném pohledu?
Pokud máte jedinečný produkt na webové aplikace, tj. pravděpodobně máte jen jeden navigační lišty, pouze jeden chat popup, pokud vůbec, pouze jeden navigační lišty logo a pouze jeden zápatí pro pojmenování některých, proč budete muset přidat je to styl globální? Není to tak špatná praxe, která je v rozporu se všemi ostatními jazyky po celém světě?,
jako doplněk, řekněme, že máte 5 pohledů na váš projekt. Pokud máte <nav> to bude pravděpodobně zobrazí na všech z nich, takže stejný styl si dát pod #primary-navigation pracuje na 5 různých názorů. Není to způsob opětovné použitelnosti?
Chcete-li zvýšit hloupost kolem toho, že obě pravidla dohromady, podívejte se, jak vám to umožní v obtížné situaci.,
Pokud nemůžete použít id pro stylování <nav class="dark-theme">, a nemůžeš přidat přilehlé třídy<nav class="primary-navigation dark-theme">, jak se budete řídit do své působnosti styling a dělat to více udržovatelný, čitelného a jak se vám to podařilo přidat java-script posluchače událostí, v případě potřeby na efektivní způsob?
prostě nemůžete.
Co bychom mohli sémanticky opravit a snadno udržovat?, Pojďme příkladem:
Zde je další prohlášení, že se mi smát na chvíli:
Vyhněte se nekvalifikovaný atribut selektorů „Nekvalifikovaný atribut selektorů, jako jsou , odpovídají všechny prvky první a pak zkontrolovat jejich atributy. To znamená, nekvalifikovaný atribut selektorů mají stejné funkční vlastnosti jako univerzální volič (*)“
Můj miláčku, to není odlišné od toho, co se stalo, když pomocí třídy nebo id, nebo tag selector.
fáze Vykreslování CSS prohlížeče jsou:
- budování DOM., DOM je stromová datová struktura obsahující všechny uzly HTML na stránce. Každý uzel obsahuje data o tomto prvku HTML (například atributy, ID a třídy) pokud má uzel jako děti nějaké prvky HTML, bude také ukazovat na tyto podřízené uzly.
- budování CSSOM. Když prohlížeč narazí na CSS stylesheet (buď vložený nebo externí), musí analyzovat text do něčeho, co může použít pro rozvržení stylů a barev. Datová struktura, do které prohlížeč změní CSS, je kreativně pojmenována CSSOM.
- generování vykreslovacího stromu., Stručně řečeno, render tree obsahuje všechny informace potřebné pro prohlížeč k vytvoření pixelů na stránce. Prohlížeč v podstatě vezme DOM a CSSOM a rozdrtí je dohromady a odstraní vše, co nebude mít vliv na vykreslený výstup.
- rozložení a malování.
na Rozložení fáze, prohlížeč zjistí velikost a polohu prvků (nic poskytnuté zatím) a pak, na laku krokem je začít vytvářet pixelů, které budeme vizualizovat.,
Jak můžete vidět, můžete získat trochu výkonu zkreslení při hnízdění bez rozdílu své voliče, jako body>#main-content>.first-block .products-card p jak budete vytvářet zbytečné podřízené uzly do CSSOM, že bude třeba, aby odpovídaly DOM a to bude trvat trochu více času, než pomocí jednoduše.products-card p, ale stejně budeme muset udržet tento kód a pravděpodobně měřítku, musíme působnosti pravidla tak, řekněme #main-content .products-card p.
je to dobrá praxe, ale nikdy jsem neviděl webovou aplikaci, ve které konkrétnější selektory způsobují zúžení rychlosti zatížení., Toto je obvykle způsobeno tím, iterace znovu a znovu udržet tóny nepoužitý kód, který prohlížeč bude přidat do CSSOM a bude třeba porovnat s DOM zjistit, jestli je to v POŘÁDKU, aby ji přidat do vykreslení stromu, nebo ne.
pro tento a další mnoho důvodů je důvod, proč najdete články vysvětlující každý špatný bod na CSSLint, jako je tento, který vysvětluje věci rozsáhlejším způsobem, než jsem tady.
shrnutí
Linters jsou dobré pro některé věci a špatné pro ostatní.,
také může být upraven, aby se vešly nějaký projekt potřebuje, nebo nějakou společnost nebo osoba preference pro zamezení těchto pravidel, které mají vlastní názor a přidávám další cenné pravidel, které odpovídají projektu.
Existuje mnoho důvodů pro použití lintr na interpretované jazyky (na sestaven ty, IDE a kompilátor se postará o to, ale můžete také přidat nepouští Vlákna zkontrolovat kód, pouze formátování nebo pro získání varování před sestavit, aby se zabránilo čekání, až překladač najde chybu nebo končí vědět, jestli je vše OK).,
Existuje několik důvodů pro přidání lintr do HTML (pouze přístupnost účely může být užitečné, myslím) a tam je méně důvodů pro přidání lintr na CSS (to může být snížena na kód, formátování, kontrola).
už jste použili vlákna? Pokud ano, řekněte nám, v jakém jazyce a kontextu a jaké byly vaše zkušenosti.
osobně se mi to líbilo po několika vylepšeních při použití TypeScriptu.
jako vždy, Doufám, že se vám tento příspěvek líbí a s pozdravem,
Joel