CSS: oddělte vzhled od struktu

Typická chyba je snaha udržet poměr 70/20/10 za každou cenu. Pokud tým tráví víc času opravováním testů než psaním kódu, poměr je špatně. Další častá chyba je nahrazení pomalu běžících end-to-end testů jednotkovými testy, které ale netestují integraci. Výsledkem je zelená sada, která nic neověřuje. Pyramida má sloužit toku hodnoty, ne naopak.

Poslední pravidlo zní: verzujte i drobnosti a průběžně. Odkládat první commit do chvíle, kdy je vše hotové, znamená přijít o celou historii . Radši méně souborů a častěji než jeden velký krok jednou za měsíc. Verzování není administrativa navíc, je to nástroj, který vám umožní vrátit se k funkčnímu stavu, porovnat varianty a vysvětlit, proč je kód takový, jaký je.

Testování idempotence patří do běžných testů. Odešlete stejný požadavek dvakrát, třikrát a sledujte, zda vznikne jediný záznam. Zkuste souběh dvou požadavků těsně po sobě a ověřte, že jeden dostane konflikt. Zkuste také požadavek s klíčem, který už expiroval. Bez těchto testů se chyba projeví až v provozu, kdy je oprava drahá. Idempotence není vlastnost, která vznikne sama. Je to rozhodnutí v návrhu API a v datovém modelu.

Interní závislosti a rozsahy, které lžou Klíčové je, jak zapisujete interní závislosti. Pokud v package.json uvedete konkrétní verzi, kterou jste právě publikovali, build lokálně projde, ale po merge do hlavní větve se rozbije, protože balíček ještě není v registru. Řešení je používat rozsah, který odpovídá strategii: u svázaných verzí stačí odkaz na workspace, u nezávislých je bezpečnější caret rozsah nebo přesné sladění přes nástroj pro správu verzí. Nikdy nenechávejte v manifestu ručně vepsanou verzi, kterou jste si opsali z výpisu.

Častou chybou je příliš agresivní limit, který zablokuje i běžné procházení. Uživatel, který rychle kliká, může narazit. Proto vždy nastavte limit s rezervou a testujte. Další chyba je ignorování hlaviček z proxy. Pokud nepoužijete správné nastavení, všechny požadavky přijdou z IP proxy a vy zablokujete celý svět. Také nedělejte rate limiting na úrovni celé aplikace, pokud to není nutné. Lepší je aplikovat ho jen na kritické routy pomocí router-level middlewaru.

Základem je rozhodnout, jestli chcete verze svázané (fixed) nebo nezávislé (independent). Svázané znamená, že všechny balíčky sdílejí jedno číslo verze a vydávají se společně. Nezávislé dovolují každému balíčku vlastní číslo, ale vyžadují spolehlivou automatizaci. V praxi se svázané hodí pro těsně provázané sady, nezávislé pro velké repozitáře, kde se balíčky vyvíjejí různým tempem. Špatná volba se neprojeví hned, ale po několika releasech začne bolet.

Začít s verzováním není o tom naučit se nazpaměť desítky příkazů. Většina webových vývojářů selže na něčem jiném: začnou verzovat příliš pozdě, příliš pozdě si nastaví ignorování souborů a příliš dlouho pracují přímo v hlavní větvi. První krok proto není instalace nástroje, ale rozhodnutí, co vůbec verzovat a co ne. Do repozitáře patří zdrojový kód, konfigurace šablon a skripty. Naopak závislosti, build artefakty, lokální konfigurace s hesly a nahrávané soubory od klientů tam nepatří. Pokud tohle nerozlišíte hned nábytek na míru začátku, první commit bude obsahovat tisíce souborů a historie se stane nepoužitelnou.

Hlavní větev není pracovní plocha Druhá častá chyba je představa, že stačí commitovat a nahrávat rovnou do hlavní větve. U malého projektu to chvíli funguje, ale jakmile se přidá druhý člověk nebo experimentální úprava, začne vznikat zmatek. Zaveďte jednoduché pravidlo: každá změna, která má vlastní účel, dostane vlastní větev. Vytvořte ji z aktuálního stavu hlavní větve, pracujte v ní, commitujte po malých krocích a teprve hotovou věc sloučte zpět. Malé commity s výstižnou zprávou vám po půl roce řeknou, proč se řádek změnil. Zprávy typu „oprava" nebo „úpravy" tuto informaci nesdělují a při hledání chyby jsou k ničemu.

Dejte pozor na tagy a větve. Každý publikovaný balíček potřebuje vlastní tag, obvykle ve tvaru názvu a verze. Pokud tagy pletete dohromady nebo je vytváříte až po publikaci, přijdete o možnost dohledat, co přesně vyšlo. Stejně tak nestačí jen sloučit pull request; publikace musí být samostatný krok, který proběhne až po úspěšném buildu a testech. Jinak se stane, že se do registru dostane verze, která neodpovídá žádnému commitu.

Před sloučením větve si vždy projděte rozdíly, které přináší. Nejde o formalitu – právě tady se odhalí omylem přidaný soubor, nechtěná změna konfigurace nebo konflikt, který jste vyřešili špatně. Pokud pracujete ve více lidech, sloučení do hlavní větve dělejte přes požadavek na sloučení, ne přímým zápisem. Ušetříte si situaci, kdy jeden vývojář přepíše práci druhého, protože měl lokálně starší verzi. Stejně tak nikdy neposílejte do sdíleného repozitáře přepsanou historii bez předchozí domluvy s ostatními.