Každý vývojář se snaží psát čistý, udržovatelný a funkční kód, ať už hackuje na straně serveru nebo fušuje na straně klienta. Během několika posledních dekád webu jsme se poučili z některých našich raných chyb a vytvořili jsme web neustále se měnících osvědčených postupů. Tyto osvědčené postupy nás obvykle chrání před problémy, ale některé z nich jsou brány příliš doslovně, až do bodu, kdy se vývojáři stanou příliš rigidními a hraničně zmrzačenými. Po pravdě řečeno, s těmito osvědčenými postupy je většinou dobré se řídit, nejsou prolomeny samolibostí, ale nutností. Zde je pět osvědčených postupů, které nejsou tak realistické, jak bychom si rádi mysleli.
"Nepřidávejte globální hodnoty do window." "
."
Vývojáři JavaScriptu vynakládají velké úsilí na zapouzdření svého kódu, jako je vytváření tříd, uzávěrů a modulů. Souhlasím s mentalitou, že byste se měli vyhýbat globálům, ale někdy prostě musíte. Doporučuji vytvořit jeden globální objekt pojmenovaný podle názvu projektu (Dojo Toolkit používá dojo a Groupon Groupon objekt) a na něm označovat vlastnosti. Vytvoření armády globalů vás může dostat do problémů, ale přidáním několika globalů do window je to v pořádku, ne-li nevyhnutelné. Dokud znáte prostředí, ve kterém bude váš kód běžet, nenarazíte na problémy s kolizemi pojmenování.
"Přidávání do nativních prototypů je špatné"
Rané rámce JavaScriptu jako Prototype a MooTools si nejprve získaly popularitu, protože umožňovaly prototypy nativních objektů. Už jste nepsali globálně dostupné funkce pro úpravu instancí String, Number, Array, Object, Function, atd. - mohli jste připnout metody na prototyp pro každou, takže tyto metody měla každá existující a budoucí instance; celkové zvýšení produktivity a efektivity kódu. Poté, po několika nových tajných dohodách o názvech kvůli standardním a proprietárním implementacím rozhraní API pro web a prohlížeč, vývojáři tuto praxi zapnuli až do bodu, kdy myšlenka přidat metodu k nativnímu prototypu znamenala, že byste měli odevzdat svůj odznak pověření vývojáře.
Hodně s přidáním global do window Přidání metod do prototypu nativního objektu je v pořádku provedeno správně. Pojmenujte svou novou metodu správně (tj. nedávejte své metodě běžný název) a budete v pohodě. Neříkám vám, abyste to dělali příliš často , Jednoduše říkám, že přidání metody do prototypu vaši kariéru nezastaví se skřípěním.
"Nikdy nepoužívejte UA Sniffing"
Čmuchání uživatelských agentů dostalo shnilý název, protože původně sloužilo k čichání funkcí, a víme, jak špatně to dopadlo. Věřte tomu nebo ne, ale většina velkých webů stále používá UA sniffing k detekci mobilních zařízení a následnému přesměrování uživatelů na mobilní verzi webu. A víš ty co? Je to spolehlivé a v nejlepším zájmu našich uživatelů. Byl jsem dotázán:"Co když uživatel podvrhne uživatelského agenta?" Moje odpověď zní:"Pak získají zobrazení libovolného webu, který s tím přichází, takže koho to zajímá? Udělali to schválně a pokud získají nefunkční web, je to jejich problém." Pokud poskytnete odkaz na počítačovou verzi webu, budete v pohodě.
"Je v pořádku načíst [knihovnu JavaScriptu] z CDN, protože uživatel ji pravděpodobně již načetl"
Tenhle mě opravdu pálí, zvláště po mé cestě do Brazílie na propagaci Firefox OS. Ano, načítání utilit z CDN je rychlé a za předpokladu, že CDN používá dostatek lidí, existuje slušná šance, že uživatel bude mít kód uložený v mezipaměti, ale není to tak jednoduché. Za předpokladu, že web má například mezipaměť jQuery, je riskantní, protože v daném okamžiku existuje mnoho verzí a subverzí a subverzí. Pokud uživatel nemá neomezený datový tarif (který není ve většině zemí nabízen), může platit poměrně dost za každý web, který používá knihovnu JavaScript nebo web, který načítá velké soubory, CDN nebo ne. Když jsem šel do Brazílie, musel bych zaplatit 20 centů jen za jQuery, pokud bych šel na web, který jej používá. Stručně řečeno:předpokládat, že uživatelé nebudou platit pokutu za zdroj hostovaný v CDN, je špatná, špatná mentalita.
„Dokonalost pixelů je nutností“
Kvalitní designéři a vývojáři bývají perfekcionisté, proto se jim daří. Když však převádíme z návrhu na pracovní stránku, dostáváme se do dokonalosti pixelů – pravděpodobně proto, že dokonalost pixelů je dosažitelný. Problém při zaměření na dokonalost pixelů je v tom, že posedlost vede ke spoustě času, který nezlepšuje uživatelský zážitek, ale posiluje naše ego. Jiní návrháři a vývojáři samozřejmě přijdou na web a všimnou si zvláštního problému se šířkou nebo výškou, ale více než 90 % uživatelů by preferovalo, abychom provádění daného úkolu usnadnili, aniž bychom zajistili přesné měření každého sloupce. Samozřejmě nedoporučuji, abyste vytvářeli weby s „nášľapními minami“ s vypnutými pixely, ale někdy je potřeba nahlásit chybu, kterou později opravíte, aby byl váš web použitelnější, přístupnější a zábavnější!
Je důležité, abychom neztráceli ze zřetele praktičnost, když se snažíme držet osvědčených postupů. Na určité praktiky se můžeme dívat přísně, ale nejdůležitější je, že vytváříme funkční a použitelné webové stránky. Nikdy nepřijímejte pravidlo, aniž byste zpochybňovali jeho celkovou platnost, a nikdy se nebojte vykročit mimo strnulé myšlenkové pochody!