CSS se připojuje buď přímo do dokumentu, nebo jako samostatný soubor. Samostatný soubor je lepší, protože se stejné styly dají použít na více stránkách a prohlížeč si je uloží do mezipaměti. Selektorů existuje několik typů: podle názvu značky, podle třídy a podle identifikátoru. Třídy se používají opakovaně, identifikátor má být na stránce jen jednou. Záměna těchto dvou věcí vede k nepředvídatelným výsledkům a kódu, kterému po týdnu nikdo nerozumí.
Typická chyba je snaha izolovat všechno. Mockovat databázi, HTTP klienta i čas najednou vede k testům, které ověřují mocky, ne kód. U integračních testů je lepší použít skutečnou databázi v kontejneru nebo lehkou instanci a připravit data před každým testem. Pokud test závisí na datech z produkce, je křehký a nikdo mu nebude věřit.
Růst codebase se projeví nejdřív na testech. Sada, která běžela dvě minuty, najednou trvá dvacet a padá z důvodů, které nesouvisí s kódem. Většina týmů reaguje přidáním dalších testů, čímž problém zhorší. Řešení není víc testů, ale jasné rozdělení odpovědností mezi jednotkovou a integrační vrstvou.
Lidé jsou třetí a největší překážka. Pokud provozní tým cítí, že mu vývojáři předávají nehotovou práci, a vývojáři zase, že je provoz brzdí, žádná automatizace to nespraví. Pomáhá společné vlastnictví služby, společné pohotovosti a to, že se incidenty rozebírají bez hledání viníka. Chyby se mají zapisovat a opravovat v systému, ne v lidech. Teprve když obě strany vidí stejná data a mají stejný cíl, začne DevOps dávat smysl.
Typická chyba začátečníků je, že commitují příliš velké změny najednou. Napíšou tři nové sekce, přepíšou styly a opraví chybu v JavaScriptu – a to všechno v jednom commitu s popisem „update". Za měsíc nebudeš vědět, co se změnilo a proč. Drž se pravidla, že jeden commit řeší jednu věc. Zpráva má být krátká a výstižná, například „oprava responzivního menu" nebo „přidání validace formuláře". Česky, anglicky, ale hlavně konzistentně.
Začnete tím, že si nainstalujete TypeScript globálně nebo lokálně do projektu a vytvoříte konfigurační soubor tsconfig.json. V něm nastavíte cíl kompilace, povolíte přísné kontroly a určíte, kam se má výsledný JavaScript ukládat. Pro nový projekt je rozumné zapnout "strict": true. Zpočátku to bolí, protože kompilátor hlásí i to, co jste dřív přehlíželi. Vyplatí se to ale vydržet: přísný režim vás naučí psát typy pořádně a předejde řadě problémů později.
Jak vypadá první commit bez zbytečných chyb Než uděláš první commit, nastav si jméno a e-mail, které se budou zapisovat do historie. Pak inicializuj repozitář příkazem git init ve složce projektu. Následuje git add ., ale pozor – tím přidáš úplně všechno, včetně souborů, které jsi chtěl vynechat. Proto je lepší nejdřív zkontrolovat stav přes git status a teprve potom přidávat konkrétní soubory nebo celé složky. První commit by měl obsahovat základní kostru projektu, ne rozdělanou práci.
Dalším krokem je větev. Větve ti umožní pracovat na nové funkci, aniž bys zasáhl do hlavní verze. Vytvoříš ji příkazem git branch nazev-vetve a přepneš se do ní přes git checkout nazev-vetve. Až je práce hotová a otestovaná, sloučíš ji zpět do hlavní větve. Právě tady vzniká nejvíc konfliktů. Když dva lidé upraví stejný řádek, Git neví, kterou verzi zachovat. Řešení je ruční: otevřeš soubor, najdeš značky konfliktu, rozhodneš, co tam má zůstat, a změnu uložíš. Čím menší změny a čím častější sloučení, tím méně bolesti.
Poslední věc, na kterou se zapomíná, je záloha. Lokální repozitář je fajn, ale pokud ti odejde disk, historie je pryč. Proto se vyplatí mít vzdálený repozitář, kam budeš pravidelně odesílat změny. Není to o tom, komu data svěřuješ, ale o tom, že máš druhou kopii. Ať už zvolíš jakoukoli službu, princip je stejný: propojíš lokální repozitář s vzdáleným a po každé ucelené práci odešleš změny nahoru. Verzování se tak stane přirozenou součástí vývoje, ne otravnou povinností na konci dne.
Prvním krokem je rozhodnout, co vlastně verzovat. Pokud děláš statický web, patří do repozitáře zdrojové soubory: HTML, CSS, JavaScript, obrázky, konfigurace. Naopak složky jako node_modules, buildované soubory nebo lokální nastavení editoru tam nepatří. Ty se řeší pomocí souboru .gitignore, který říká, co má Git ignorovat. Bez něj ti během chvíle nabobtná historie o tisíce zbytečných souborů a orientace v commitech se změní v noční můru.
Verzování není jen nástroj pro týmy, které spolupracují na velkém projektu. Pro webového vývojáře je to způsob, jak se přestat bát experimentovat. Když máš každou změnu v HTML, CSS nebo JavaScriptu uloženou v historii, můžeš zkoušet nové věci, aniž bys riskoval, že rozbiješ funkční verzi. Stačí jedna složka, jeden příkaz a začneš.