• 목록
• 답변
• 글쓰기
• 게시판 리스트 옵션
  • 수정
  • 삭제

Na závěr si pohlídejte, jak tokeny přijímáte. Vždy ověřujte, že přicházejí jen z očekávaných zdrojů, a omezte CORS na konkrétní domény, kterým důvěřujete. Kontrolujte také, že algoritmus v hlavičce tokenu odpovídá tomu, který jste nastavili na serveru. Tím zabráníte útokům typu alg confusion. všelék, ale když respektujete jeho principy – krátkou platnost, silný podpis a bezpečné uložení – získáte solidní základ pro ochranu vašeho API bez zbytečné složitosti.

Stanovit termín dodání je byt v panelákuždy riskantní. Když řeknete „bude to za týden", zákazník si to uloží do hlavy jako pevný slib. Jakmile práce skončí za deset dní, cítí zklamání, i když bylo zpoždění způsobeno objektivními okolnostmi. Klíčem k úspěšné komunikaci odhadů není být vždy přesný, ale nastavit očekávání tak, aby drobné odchylky neznamenaly ztrátu důvěry.

Na závěr si osvojte práci se vzdáleným repozitářem. Lokální historie je sice užitečná, ale skutečnou jistotu získáte teprve tehdy, když svůj kód pravidelně posíláte na vzdálený server. Tím si chráníte práci před selháním disku a umožníte spolupráci dalším lidem. Pravidelně také stahujte změny od kolegů a řešte konflikty hned, ne až těsně před nasazením. Verzování není nástroj na uskladnění kódu, ale způsob, jak mít celý vývoj pod kontrolou – a to se vyplatí.

Naučte se psát smysluplné zprávy k commitům. Místo „oprava" nebo „update" pište konkrétně, co a proč jste změnili, třeba „oprava responzivního menu na mobilních zařízeních" nebo „přidání validace emailu do registračního formuláře". Dobrá zpráva vám po půl roce řekne, co se dělo, aniž byste museli otevírat celý diff. Naopak vágní popisky jsou k ničemu, zvlášť když potřebujete najít konkrétní změnu v historii.

Nejdřív si ujasněte, co budete verzovat. Webový projekt obvykle obsahuje zdrojové kódy, šablony, styly, skripty a konfigurační soubory. Do verzování nepatří vygenerované soubory, jako jsou minifikované CSS nebo JavaScript, cache, nahrané obrázky ani lokální konfigurace s hesly. Pro tyto soubory si připravte seznam ignorovaných souborů hned na začátku. Pokud ho nevytvoříte, budete do historie ukládat balast, který znepřehlední každý diff a zpomalí práci s repozitářem.

Typové systémy se neomezují jen na primitivní typy. Prakticky využijete generické funkce, které umožňují zachovat typovou informaci napříč logikou. Například funkce pro získání prvku z pole podle indexu může vracet typ prvku pole, nikoli univerzální objekt. Tím dosáhnete toho, že kód bude znovupoužitelný a zároveň typově bezpečný. Také si osvojte práci s typovými predikáty a diskriminovanými uniemi. Tyto techniky vám umožní modelovat složitější domény, jako jsou stavy formuláře, výsledky síťových požadavků nebo různé varianty dat, aniž byste museli používat obsáhlé hierarchie tříd.

Většinu práce dělejte ve vlastní větvi, ne přímo v hlavní. Hlavní větev by měla vždy obsahovat stabilní, nasaditelnou verzi webu. Pro novou funkci nebo opravu si vytvořte větev s popisným názvem, pracujte v ní a po dokončení ji slučte zpět. Tím zajistíte, že hlavní větev nezahltíte rozpracovaným kódem a kolegové (nebo vy sami) budou mít vždy jistotu, že hlavní větev je použitelná. Typická chyba je dlouhodobě pracovat v hlavní větvi a slučovat až na konci – to vede ke konfliktům a zmatkům.

Verzování webu už dávno není volitelné. Pokud nepoužíváte systém pro správu verzí, každá větší úprava šablony, skriptu či konfigurace znamená riziko, že něco rozbijete a už to nevrátíte zpět. Začít přitom není složité, stačí se vyhnout pár základním nástrahám. Tento text vám ukáže, jak na to, a upozorní na časté chyby, které dělají i zkušení vývojáři.

Před každým commitnutím si projděte rozdíly mezi tím, co jste změnili, a tím, co je v repozitáři. Necommitujte naslepo všechny soubory najednou. Pokud jste v jednom souboru změnili dvě nesouvisející věci, rozdělte je do dvou commitů. Tím získáte čistou historii, kterou lze snadno vracet zpět. Když něco rozbijete, budete moci vrátit jen tu konkrétní změnu, ne celý den práce. Tento návyk oceníte hlavně při ladění, kdy hledáte, která úprava způsobila chybu.

Jak vypadá první commit a proč ho nedělat narychlo Než provedete první commit, inicializujte repozitář v kořenovém adresáři projektu a zkontrolujte, co se vlastně bude verzovat. Pomocí příkazu pro zobrazení stavu si projděte všechny soubory a ujistěte se, že neobsahují žádná tajemství, jako jsou přihlašovací údaje do databáze nebo API klíče. První commit by měl obsahovat kompletní funkční základ projektu, ne jen polotovar. Typická chyba začátečníků je, že commitnou celý adresář s vendor knihovnami nebo node_modules, a pak se diví, proč je repozitář obrovský a pomalý.