Konflikty řešte hned, ne odkladem. Pokud při rebase narazíte na konflikt, přečtěte si obě strany a rozhodněte, která verze je správná. Nikdy nenechávejte v souboru značky konfliktu ani „obě varianty" pro jistotu — tím vzniká kód, kterému nikdo nerozumí. Po vyřešení spusťte testy znovu, protože sloučení mohlo změnit chování i tam, kde konflikt nebyl.

Praktický postup: začněte tam, kde vás chyba bolí nejvíc. Pokud často padá nasazení kvůli nekompatibilitě rozhraní, přidejte integrační testy. Pokud se opakovaně vrací chyby ve výpočtech, posilte unit testy. End-to-end testy pište jen pro případy, které by při selhání znamenaly okamžitou ztrátu uživatelů nebo dat. A vždy měřte dobu běhu – pokud testovací sada přesáhne několik minut, vývojáři ji přestanou spouštět lokálně.

Neignorujte chybová hlášení. Podrobná chybová zpráva z databáze prozradí názvy tabulek, sloupců i typy dat a útočníkovi výrazně usnadní další postup. V produkčním prostředí proto zapněte obecné chybové stránky a podrobnosti logujte pouze na server. Totéž platí pro ladící nástroje, které nesmí být veřejně dostupné.

Pyramida není o počtech, ale o rovnováze. Když dole rychle odhalíte většinu chyb, nahoře vám zbyde prostor pro scénáře, které opravdu simulují uživatele. Až budete příště přemýšlet, kam napsat další test, zeptejte se: jak rychle mi dá odpověď a jak drahá bude jeho údržba? Odpověď vás udrží na správné straně pyramidy.

Verzovací systém není nástroj, který si nastavíte jednou a pak na něj zapomenete. U webových projektů se do něj sahá několikrát denně, takže záleží hlavně na návycích. První krok nejsou příkazy, ale rozhodnutí, co vlastně chcete sledovat. Do repozitáře patří zdrojové soubory, konfigurace šablon, skripty sestavení a dokumentace. Naopak závislosti stažené správcem balíčků, výstupní složky sestavení, lokální konfigurace s hesly a nahrané soubory od uživatelů tam nepatří.

Typická chyba je snaha vyřešit všechno na místě. Tým vybere pět problémů, u každého se dohodne úkol a za týden není hotové nic. Lepší je vzít jeden až dva konkrétní kroky, určit, kdo je udělá, a na příští schůzce začít tím, jestli se povedly. Pokud se opakovaně nedaří ani jeden krok, není problém v retrospektivě, ale v prioritách nebo v kapacitě týmu. To je legitimní zjištění, které patří na stůl, ne pod stůl.

Základem je konzistence. Stejné prvky se chovají stejně na všech obrazovkách. Pokud tlačítko „Uložit" vypadá jednou tak a podruhé jinak, uživatel ztrácí jistotu. Vytvořte si jednoduchý styl – barvy, písmo, rozestupy – a držte se ho. Neznamená to, že nemůžete být kreativní, ale kreativita má sloužit srozumitelnosti, ne naopak. Když vývojář pochopí, že UI a UX nejsou o kráse, ale o funkci, začne stavět aplikace, které lidé chtějí používat.

Testovací pyramida není dogma, ale nástroj pro rozhodování, kam investovat čas. Většina týmů ji ale používá špatně: postaví ji vzhůru nohama a pak se diví, že zpětná vazba trvá hodiny a opravy jsou drahé. Cílem je mít hodně rychlých testů dole a málo pomalých nahoře. Ne proto, že to zní hezky, ale protože čím později chybu odhalíte, tím víc vás stojí.

Na co si dát pozor: nesnažte se mít sto procent pokrytí, to je past. Sledujte raději, které části kódu mají nulové pokrytí a přitom jsou kritické. Dále nepište testy, které jen kopírují implementaci – takové testy neodhalí chybu, pouze zvyšují údržbu. A nezapomeňte na izolaci: každý test musí být nezávislý na ostatních a na pořadí spuštění. Pokud test závisí na datech z předchozího testu, dříve nebo později selže v produkci.

Typická chyba je přesný opak: tým napíše stovky end-to-end testů, protože „testují jako uživatel". Jenže tyto testy jsou pomalé, křehké a jejich selhání často nesouvisí s kódem, ale s prostředím. Výsledkem je, že vývojáři přestanou testům věřit a začnou je ignorovat. Přitom stačí držet poměr: mnoho unit testů, méně integračních, jen hrstka end-to-end pro klíčové scénáře.

Kde se pyramida láme Základ tvoří unit testy. Mají být rychlé, izolované a deterministické. Pokud jeden test trvá déle než pár milisekund, něco je špatně – nejčastěji saháte na databázi, souborový systém nebo síť. Druhá vrstva jsou integrační testy: ověřují, že spolu komponenty skutečně komunikují. Třetí vrstva, end-to-end testy, simuluje reálné scénáře přes celou aplikaci. Ty jsou nejužitečnější pro ověření kritických cest, ale také nejdražší na údržbu.

Vývojáři často berou design jako něco, co se dá dodělat na konci. Jenže UI a UX nejsou dekorace. Jsou to nástroje, které rozhodují o tom, zda lidé vaši aplikaci použijí, nebo ji po pár sekundách zavřou. Pokud chcete, aby vaše práce měla smysl, musíte design řešit od začátku, ne jako vrstvu navrch.